инструменты проектирования схем баз данных / модульное проектирование баз данных

Question

Я занимаюсь разработкой приложений, которые могут быть собраны частично из модулей. Например, я смогу разработать какое-то онлайн-сообщество, содержащее модули «форум», «блог», «галерея» и т. Д.

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

Однако я не смог найти никаких инструментов, которые бы поддерживали это - это неправильный путь или как вы разрабатываете "модульные ERM" / схемы модульных баз данных?

спасибо!

Answer 1

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

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

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

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

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

Answer 2

Я согласен, что модульный дизайн - это путь. Когда мы создаем приложения для клиентов, мы склонны продавать им коллекцию уже созданных виджетов. Так что же происходит, когда клиент говорит «Я посетил веб-сайт X, и мне нравится его виджет Y. Вы можете добавить это в мое приложение / веб-сайт?»

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

Проверьте эту ссылку и источники, указанные в примечаниях.

MediaWiki Design - см. Примечания внизу

Answer 3

Я предпочитаю использовать схемы. Это естественный способ инкапсулировать проблемную область (будь то схема для модуля или схема, охватывающая информационную область).

Я использую PostgreSQL, и я предпочитаю писать инициализацию db самостоятельно (я хочу иметь 100% -ый контроль, и SQL настолько явный, насколько это возможно.). Я использую SchemaSpy для генерации ER диаграмм. У меня не было проблем с несколькими схемами и внешними ключами в разных схемах - не уверен, как это работает в MySQL.

Я не знаком с упомянутым вами инструментом, однако на снимке экрана показано, что они поддерживают схемы. Может стоит проверить еще раз. http://www.dbwrench.com/screenshots/xp_explorer.shtml

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

Answer 4

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

Answer 5

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

grant DELETE, INSERT, UPDATE, SELECT on parentUser.table1 to childUser;
CREATE OR REPLACE SYNONYM childUser.table1 FOR parentUser.table1;

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