Любые рекомендации для эффективного способа синхронизации данных из одной базы данных, в базы данных другого приложения? - PullRequest
1 голос
/ 29 марта 2010

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

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

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

Я ищу мнения о некоторых способах сделать это.

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

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

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

1 Ответ

3 голосов
/ 30 марта 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...