Определение схемы базы данных в приложении или в базе данных?

Question

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

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

Answer 1

Имейте в виду, что приложения и базы данных имеют тенденцию жить в отношениях M: M в любых, кроме самых тривиальных случаях. Если ваше приложение может иметь интерфейсы к другим системам, отчеты, извлечения или загрузки данных или данные, перенесенные в или из нее из другой системы, то в базе данных имеется более одного участника. Будьте добры к другим заинтересованным сторонам в вашем приложении. Потратьте время и разработайте правильную схему и подумайте о качестве данных при разработке вашего приложения. Следите за тем, кто использует приложение, и следите за тем, чтобы не нарушать биты схемы, от которых они зависят, не сказав им об этом. Это означает, что база данных имеет собственную жизнь в большей или меньшей степени. Чем больше интеграция, тем независимее база данных.

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

Answer 2

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

Конечно, у меня есть только несколько крупных проектов. Я все еще учусь ежедневно. :)

Answer 3

Много зависит от вашего уровня квалификации с конкретным продуктом базы данных, который вы собираетесь использовать. Думайте об этом как о разнице между «ручной» и «автоматической» коробкой передач автомобиля. ORM предоставляют вам эту «автоматическую» передачу, просто начните проектировать свои классы и позвольте ORM беспокоиться о том, чтобы как-то сохранить их в базе данных.

Звучит хорошо. Проблема большинства ORM состоит в том, что в своем стремлении быть PI «невежественным персистентностью» они часто не используют преимущества конкретных функций базы данных, которые могут предоставить элегантные решения для конкретной задачи. Обратите внимание, я не сказал ВСЕ ОРМ, только большинство.

Мое предположение - сначала разработать концептуальную модель данных. Затем вы можете двигаться в любом направлении: вверх, к области приложения или вниз, к физической базе данных. Но помните, только ВЫ знаете, выгоднее ли использовать представление вместо таблицы, если вы нормализуете или отменяете нормализацию таблицы, какой некластерный индекс (ы) имеет смысл с этой таблицей, является ли естественный или суррогатный ключ более подходит для этой таблицы и т. д. ... Конечно, если вы считаете, что эти вопросы вам не под силу, тогда позвольте ORM помочь вам.

Еще одна вещь, вам действительно нужно отделить дизайн приложения от дизайна базы данных. Они почти никогда не бывают одинаковыми. Насколько важны эти данные? Может ли другое приложение быть разработано для использования этих данных? Рефакторинг приложения намного проще, чем рефакторинг базы данных с миллиардом строк данных, распределенных по тысячам таблиц.

Answer 4

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

Я думаю, что это лучший способ, потому что на самом деле база данных - это просто место для хранения информации из приложения, она никогда не должна руководить проектом. Это не единственное место для сохранения информации. У нас есть пользователи, которые хотят работать с плоскими файлами или базой данных, например. Они также могут использовать файлы XML. Таким образом, если начать с ваших доменных объектов, а затем сгенерировать таблицы (или простой файл, или XML-схему или что-то еще) из этого, то в итоге вы получите гораздо лучший дизайн.

Хотя это может зависеть от того, используете ли вы объектно-ориентированный язык, использование инструмента ORM, такого как Hibernate / NHibernate, SubSonic и т. Д., Действительно может упростить этот переход, включая создание сценариев создания базы данных.

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

Answer 5

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

Если задуматься, ORM можно легко использовать для расширения связи (даже если в некоторой степени этого можно избежать).

Answer 6

Что ж, если вам это сойдет с рук, возможно, лучше всего это сделать в приложении. Так как это прекрасный пример принципа СУХОЙ.

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

В любом случае, вы, возможно, в конечном итоге измените схему вручную, а затем застрянете в хрупкой схеме базы данных, которая станет источником ваших худших кошмаров:)

Мои 2 цента