разработать расширяемую модель базы данных

Question

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

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

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

Answer 1

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

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

Answer 2

«В настоящее время я делаю проект, спецификации которого неясны»

Учитывая тег 'database', я предполагаю, что вы задаете этот вопрос в контексте database .

Помните, что база данных - это набор АСПЕРТОВ ФАКТА (предполагается использование заглавных букв).

Если неясно, какого рода «утверждения о фактах» хочет зарегистрировать ваш пользователь в базе данных, вы просто не сможете определить (структуру) своей базы данных.

И вы будете помогать и себе, и своему пользователю, сначала пытаясь очистить все, что неясно.

Answer 3

В простом ответе: БЫТЬ МИНИМАЛИСТИЧЕСКИМ.

Попробуйте выяснить основные сущности. Не беспокойтесь о свойствах, вы заполните их позже. Затем создайте отношения между сущностями. Создайте тестовое приложение, используя любимый ORM (Hibernate?), Создайте несколько модульных тестов и, наконец, у вас будет минимальная работоспособность БД. :)

Answer 4

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

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

Answer 5

То, что вы описываете, характерно практически для каждого проекта. Однако вы можете сделать несколько вещей.

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

Я рекомендую использовать Agile-процесс разработки: реализуйте только то, что вам нужно прямо сейчас, но убедитесь, что вы понимаете всю проблему, прежде чем ее смоделировать.

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