Comments 9
Шикарные схемы.
Мне кажется, Вы изобрели шаблонизатор. Again!
Схемы напомнили))
Серьезно? Это WordArt на схемах?
Я, конечно, дико извиняюсь, но у меня вопрос:
А использовать нормальные системы класса ETL/MDM/DQ принципиально нельзя? Ну, собственно, которые специально предназначены для решения задач сведения данных и делают это с гораздо меньшим геморроем и более высоким качеством?
А тут получился прекрасный костыль красного дерева с инкрустацией и лакировкой :)
А использовать нормальные системы класса ETL/MDM/DQ принципиально нельзя? Ну, собственно, которые специально предназначены для решения задач сведения данных и делают это с гораздо меньшим геморроем и более высоким качеством?
А тут получился прекрасный костыль красного дерева с инкрустацией и лакировкой :)
Вы про абсурдность функции Pattern ()? Мы про необходимость сохранения целостности записей на этапе обработки соответствующих этим записям данных. Заметим, что функция Pattern () упоминается вскользь. Если кому-то проще обращение к тому, что называется 'нормальные системы класса ETL/MDM/DQ', то это ничего не меняет. Смотрите нашу новую статью в продолжение темы конвертации — 'Адаптация SQL' о совместимости СУБД, где в PostgreSQL создается БД из скрипта MySQL
Объясняю. Вы здесь сосредоточены на технических деталях, а не на бизнес-результате, раз. Второе, если у вас действительно задача обработать в полезный результат миллионы исторических записей, то вы с ними делаете где-то 10% от того, что с ними СЛЕДОВАЛО бы делать. Естественно, не самодельными костылями, а специально для этого предназначенными средствами. А там используются и нечеткая логика, и подобие, и предварительная валидация/актуализация/нормализация отдельных полей, ну и вишенкой на торте — дедубликация массивов и построение мастер-массива.
То есть как самопальное, простое, и доступное решение проблемы оно, наверное, весьма даже хорошо, хотя, еще раз, бизнес-проблему оно решает на тройку с минусом. Особенно если Вам приходится сливать данные из трех-пяти унаследованных систем с целью получить нормальную, к примеру, клиентскую базу где таки одна запись-один клиент, и эта запись содержит всю совокупность информации из всех исходных источников. То есть те самые пресловутые мастер-данные, aka Customer Data Integration.
Естественно, вся эта история стоит денег, и немалых. «Но можно и не платить! Если Вас не интересует результат...» (с) Жванецкий
То есть как самопальное, простое, и доступное решение проблемы оно, наверное, весьма даже хорошо, хотя, еще раз, бизнес-проблему оно решает на тройку с минусом. Особенно если Вам приходится сливать данные из трех-пяти унаследованных систем с целью получить нормальную, к примеру, клиентскую базу где таки одна запись-один клиент, и эта запись содержит всю совокупность информации из всех исходных источников. То есть те самые пресловутые мастер-данные, aka Customer Data Integration.
Естественно, вся эта история стоит денег, и немалых. «Но можно и не платить! Если Вас не интересует результат...» (с) Жванецкий
Sign up to leave a comment.
Стандартизация записей