Советы по управлению большим количеством таблиц базы данных для данной модели базы данных

Question

Я работаю над базой данных MySQL с более чем 60 таблицами . Я использую MySQL для моделирования баз данных. Я разбил модель на несколько диаграмм.

Однако мне очень трудно управлять таким большим количеством таблиц.

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

Например, какое максимальное количество таблиц должна содержать отдельная диаграмма?

Существуют ли инструкции о том, как разбить модель на различные диаграммы? Я думаю, что каждая диаграмма должна соответствовать модулю в приложении ..

Помимо разбиения модели на несколько диаграмм, существуют ли другие способы управления сложностью модели?

Answer 1

60 на самом деле не так уж много.

Я бы определенно сделал одну общую диаграмму для модели.

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

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

Answer 2

60 не особенно большое количество таблиц, но я понимаю ваши проблемы.

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

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

Представления фактически были бы физическим представлением этих конгломератных объектов, если бы вам всегда требовалась одна и та же информация в одной и той же структуре. Например, возможно, позиция должна всегда получать статус заказа или имя клиента. Создайте представление, а затем используйте его для представления 3 таблиц на диаграмме.

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

Answer 3

Разделяй и властвуй.

Логические пространства имен уменьшают умственную нагрузку на каждого, кто имеет непосредственное отношение к базе данных.Стандартный SQL имеет способ справиться с этим: схемы SQL.

Посмотрите, как другие платформы поддерживают схемы SQL.( Как PostgreSQL поддерживает схемы SQL .) MySQL имеет специфическую поддержку схем SQL.(То есть, нет, на самом деле.) В MySQL CREATE SCHEMA создает базу данных.Это не то, что вы хотите здесь.(MySQL нелегко применять ограничения внешнего ключа в базах данных.)

Поскольку схема SQL по сути является пространством имен, вы можете имитировать некоторое использование схем SQL, добавляя префикс имени таблицы с помощью "имя схемы ".Таким образом, если вы строите систему учета, вы можете сгруппировать все таблицы дебиторской задолженности в AR-схеме, все таблицы кредиторской задолженности в AP-схеме и так далее.Вы можете сделать это путем добавления префиксов имен таблиц к «AR» или «AR_», «AP» или «AP_» и т. Д.

Это приближает схемы SQL двумя способами.Он организует таблицы сначала логически, а затем по алфавиту.И это позволяет одно и то же имя «таблицы» в нескольких «схемах».(Как "AR_employees" и "AP_employees".)

Я слышал, что говорят о поддержке внешних ключей для федеративных таблиц в MySQL 6.something.Но если это похоже на традиционную поддержку внешних ключей в MySQL, это вам не поможет.

Answer 4

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

При этом существует несколько вещей, которые вы можете сделать, чтобы помочь в управлении вещами.немного проще, например, цветовое кодирование ваших таблиц по «типу», например

1. Ассоциативные таблицы (Единицы, которые на самом деле являются просто отношением Многие-Многие)
2. Таблицы поиска(Единицы, которые просто содержат информацию о значении и не являются ядром БД)