Шаблоны для функциональной декомпозиции базы данных?

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

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

Я много читал о декомпозиции базы данных. То есть вы размещаете таблицы, относящиеся к разным доменам, в разных базах данных. Например, все, что связано с накладными и другими бумажными материалами, помещается в базу данных под названием «Бумаги», а все, что связано с клиентами и их заказами, помещается в базу данных под названием «Клиенты» и так далее.

Здесь две проблемы:

  • Пользователь должен видеть, что корпоративное приложение действует в одном домене. Разработчики должны изменить ядро, работающее с базой данных, таким образом, чтобы оно могло обращаться к нескольким базам данных.
  • Общие таблицы создают проблему. Они должны храниться в одной базе данных и не могут быть реплицированы во всех базах данных после декомпозиции. Следовательно, как нам сделать запрос SELECT * FROM A JOIN B, если A и B находятся в разных базах данных (на разных серверах)?

Оба вопроса фактически касаются одной и той же проблемы - есть ли какие-либо общие шаблоны Enterprise (например, GoF) для решения этой проблемы? Меня особенно интересуют шаблоны, подходящие для Java EE.


design-patterns database-design high-load decomposition
person SPIRiT_1984    schedule 12.11.2012    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

Re: накладная, счет-фактура и т. Д., К сожалению, MySQL не реализует Схема, как и другие СУБД, такие как MS SQL Server. Вы можете смоделировать пространство имен, присущее схеме, добавив префикс к таблицам (PaperWaybill, PaperInvoice и т. Д.).

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

ИМО, вам нужно понять основную причину, по которой так мало отношений. Возможно, что отношения существуют, однако FOREIGN KEYS были отброшены, например. по соображениям производительности. Если это мешает вам построить схему системы или мешает такому инструменту, как генератор кода ORM, создавать отношения, вы можете восстановить базу данных PROD в среде DEV и добавить внешние ключи обратно в DEV. В то же время вы получите представление о качестве данных - например, Ограничение FK.

person StuartLC    schedule 12.11.2012