Управление основными данными - избыточность данных

Question

В настоящее время я занимаюсь разработкой системы, в которой хранятся все соответствующие основные данные, например, данные о клиенте, или информация об операционной системе, существующей в нашей системной среде.Назначенные идентификаторы для этих объектов являются уникальными в пределах предприятия.Когда некоторая система хранит, например, данные, относящиеся к клиенту, она также должна содержать идентификатор основных данных клиента.Система основных данных основана на .Net и MSSQL 2005.

1. Теперь мой вопрос заключается в том, чтобы при разработке другой системы с ее собственными сборками, базой данных и т. Д. Использовать данныеСистема MDM. Будете ли вы избыточно хранить эти данные в базе данных других систем, создавать свои собственные бизнес-объекты (например, клиента) и жестко кодировать необходимые основные данные из MDM в другой базе данных (или с помощью ETL)?Таким образом, другая система отсоединяется от MDM, но хранит только глобальные идентификаторы основных данных.

2. Или вы интегрируете сборки MDM в другие системы (если, конечно, .Net)и использовать слой данных MDM для загрузки глобальных объектов (например, клиента)?

3. Или вы позволите другой системе создавать свои собственные объекты, но для извлечения основных данных вы будете использоватьИнтерфейс SOAP, предоставляемый MDM.

Я склонен использовать подход №.1, потому что я думаю, что лучше отсоединять другие системы от решения MDM (разделение проблем).Поскольку решение MDM может хранить гораздо больше данных о клиенте, чем мне нужно в какой-то другой системе, где требуется только имя клиента.Вариант 3 возможен, но веб-службы могут сильно замедлить работу операционной системы.Что ты думаешь?

Answer 1

1. Это сопряжено с высоким риском того, что данные будут синхронизированы, а затем возникнет сильная головная боль при попытке разгадать их.

2. Это жизнеспособный вариант, но вам придется поддерживать приличный набор сборок для использования людьми. Это нетривиальная задача, поскольку они должны быть надежными, хорошо документированными, иметь удобный API и некоторое разумное управление выпусками, как вы ожидаете от любой сторонней среды. В моем опыте это обычно уровень строгости выше обычных практик разработки LOB.

3. Должен быть путь, я бы сказал. Сервис-ориентированная архитектура, позволяющая другим людям получать доступ к данным, но предоставляя им гибкость в отношении доступа к ним.

Как вы говорите, производительность может быть решающим фактором - в этом случае 1 в сочетании с 3 может быть лучшим. т.е. локальные копии рассматриваются и обрабатываются как кэшированные данные, а не как надежные актуальные копии. Приложение может выполнить быструю проверку с главной базой данных, чтобы убедиться, что локальный кэш все еще действителен (очень похоже на запрос HEAD в земле HTTP), а затем либо использовать локальные данные, либо обновить их из основной базы данных.

Answer 2

Плюсы и минусы решения 1:

Плюсы: - Более быстрое время отклика (вместо необходимости консультироваться с Мастером при каждой операции, вы можете что-то кэшировать, чтобы облегчить это) - Ваша спутниковая система может работать, даже если мастер временно недоступен.

Минусы: - Вы рискуете работать с устаревшими данными (если вы обновили ETL в полночь, вы не получите никаких новых или обновленных записей до следующего полуночного цикла) - Конечно, вы не можете позволить спутнику когда-либо касаться какой-либо локальной копии MDM (двустороннее выравнивание, особенно с несколькими различными спутниками, становится кошмаром).

Так что, в зависимости от специфики, решение 1 может быть в порядке. Я бы предпочел каждый раз обращаться к Мастеру (опять же, возможно, кешируя ответы на некоторое время), но это скорее личное предпочтение.