Лучше ли моделировать базы данных после их приложений или после их компонентов?

Question

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

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

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

Answer 1

Правило следующее:

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

Яблоки и апельсины.

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

«Отчет о фруктах» для яблок и апельсинов.Сколько у нас фруктов?Сколько плодов любого рода происходит из Калифорнии?

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

Answer 2

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

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