Любые рекомендации по эффективному способу синхронизации данных из одной базы данных и баз других приложений?

Question

Вот моя проблема. Я создал веб-приложение и, естественно, сохранил данные в базе данных, которая описывает домен этого приложения. Послесловие я построил другое веб-приложение для одной и той же организации и использовал отдельную базу данных для описания домена этого приложения и хранения данных ... и, естественно, появилось еще несколько проектов, и для каждого приложения я выделил его данные в одну базу данных , Девелопмент мудрый, я думаю, что все в порядке, так как я могу поддерживать изменения в структуре данных и данных в базе данных приложения.

Учитывая, что эти приложения принадлежат к одной и той же организации, существует множество реплицированных данных между ними, таких как имена отделов, названия рабочих мест, имена магазинов и т. Д. Большинство этих таблиц содержат одни и те же данные, но не являются точными то же самое в каждой базе данных и не всегда используются всеми приложениями. Изменения этих данных, однако, должны быть изменены во всех приложениях (иногда разными способами), создавая растущие проблемы с управлением.

Так что я думал о способе получения некоторой синхронизации между данными. Я хочу упростить управление - обновить в одном приложении (или в центральном приложении) и обновить все базы данных по мере необходимости каждым приложением - а также лучший способ обмена данными между приложениями (например, возможно, вымыть данные из разных приложений в новом приложении для анализа конкретного анализа). Большинство данных, на которые я ссылаюсь, используются как недочеты больше, чем концепция основного домена, описывающая организацию, а не описание конкретного домена.

Я ищу мнения о том, как это сделать.

Моя первая идея заключалась в том, чтобы захватить структуры данных comun, например таблицу названий разделов, упомянутую мной, и stick'em в базе данных ядра. Любые обновления данных будут выполняться в этой базе данных через специальное веб-приложение, и я применил бы какой-то шаблон Observer или Publisher/Suscriber Pattern для этих изменений - при изменениях приложение будет уведомлять наблюдающие приложения (через выделенный веб-сервис) что произошли изменения и позволяют приложению захватывать новые данные и использовать их по мере необходимости. GUID могут быть пользователем в качестве ссылки для идентификации одних и тех же данных во всех приложениях. Кроме того, я мог бы создавать веб-службы для операций чтения и поиска, которые не обязательно должны быть в базе данных конкретного приложения, но могут быть полезны для него.

Вторая идея заключается в том, что каждое приложение управляет своими собственными данными, и приложения могут наблюдать друг за другом. Изменение в одном может уведомить других, которые используют одну и ту же структуру данных, что и произошло. Я все еще мог использовать некоторые GUID и даже создавать службы в любом из приложений. Я думаю, что это также было бы менее жестким с точки зрения дублирования данных, но может быть сложнее управлять, поскольку каждое приложение в конечном итоге будет связано с другими приложениями, и я бы хотел, чтобы кто-то распределял ответственность за то, какое приложение контролирует какую информацию.

Мне действительно любопытно, что что-то из этого жанра передачи данных и синхронизации будет работать и даже быть рекомендовано. Оппоненты и другие идеи более чем приветствуются!

Answer 1

Опишите здесь типичный случай для системы «Управление основными данными». Поставщики EAI (Oracle, TIBCO, IBM) предлагают такие продукты. Они напоминают ваше первое решение: централизованные базы данных с процессами синхронизации, обнаружение изменений в внешних источниках данных, захват изменений и синхронизация данных с другими внешними базами данных. Они также предоставляют пользовательский интерфейс для непосредственного изменения основных данных.
Программное обеспечение MDM дорогое, но вы можете реализовать собственное решение, которое будет - по крайней мере первоначально - дешевле, чем покупка. Оба ваших решения имеют технический смысл, но есть разница в их управляемости.
Первое, что лучше, если вы можете посвятить ответственное лицо/организацию, чтобы позаботиться об этом, и владельцы бизнеса ваших служб могут договориться о внесении изменений через эту новую централизованную систему.
Второе решение разделяет ответственность между владельцами услуг.Трудная задача здесь - определить владельца каждого типа информации (бизнес-объект).
Я не могу посоветовать решение без глубокого знания ваших систем и организаций, но я надеюсь, что смогу дать некоторые идеи.