Как мне обращаться с общей базой данных, на которую должны ссылаться несколько приложений? - PullRequest
1 голос
/ 14 января 2011

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

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

Мне не хватает хороших вариантов? Из этих двух или любых других предложенных, с кем бы вы пошли и почему?

Ответы [ 5 ]

1 голос
/ 14 января 2011

Если вы слишком беспокоитесь о ссылочной целостности ваших таблиц User и Product, я бы оставил копию этих таблиц только для чтения в нескольких базах данных и установил FK.Затем напишите единый сервис, чтобы поддерживать все копии в актуальном состоянии.

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

1 голос
/ 14 января 2011

Возможно, вы захотите посмотреть Репликация .Из вашего описания, Snapshot репликации показался бы наиболее подходящим.У вас будет одна база данных, в которой вы будете поддерживать свои общие таблицы (используя специальное приложение, или прямой SQL, или что-то еще), и тогда ваши сервисные базы данных станут подписчиками.SQL Server позаботится о копировании данных между серверами.

Вы даже можете иметь внешние ключи для общих таблиц (поскольку они появляются в каждой из баз данных службы)


Это фактически ваш вариант 2, но с заполненным битом "как синхронизировать ведущую и ведомую таблицы".

0 голосов
/ 30 января 2011

Сейчас вы в основном сравниваете простоту с производительностью (поскольку вы упомянули ссылочную целостность, это не проблема).В варианте 1 все расположено в центре и управляется, для извлечения данных потребуются дополнительные сетевые переходы, но вам не нужно беспокоиться об устаревших данных или управлении несколькими базами данных, которые могут иметь свои проблемы.Если ваш основной сервер работает, то он работает для всех.В варианте 2 локальное хранение ваших данных повысит вашу производительность, но усложнит долгосрочное обслуживание системы и создаст потенциальные проблемы несоответствия данных (хотя, учитывая, что ваши данные относятся к странам и отраслям, они, вероятно, не будут меняться очень часто, поэтому в этом нет необходимостиобновляться часто).

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

0 голосов
/ 19 января 2011

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

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

Если у вас нет особых требований, послушайте Кданского. Будь проще. Потратьте столько же времени на разработку, предоставляя своим пользователям функции ... а не на написание мониторов целостности данных.

0 голосов
/ 14 января 2011

Использовать одну базу данных со всеми таблицами, затем открыть для нее соединение обеих служб, записать чистые транзакции и разрешить свойствам ACID решать любые (маловероятные) проблемы?

Просто, эффективно, легко сделать.

Есть ли требование, которое помешало бы этому решению работать?

...