Дизайн БД: предпочтение абстракции или ограничения внешнего ключа?

Question

Скажем, у нас есть такой сценарий:

Artist ==< Album ==< Track
//ie, One Artist can have many albums, and one album can have many tracks

В этом случае все 3 сущности имеют в основном одинаковые поля:

• ID
• Имя
• Иностранец отношения «один-много» с соответствующими детьми (Исполнитель в Альбом и Альбом в Трек

---

Типичным решением для предоставленного решения являются три таблицы с одинаковыми полями (ArtistID, AlbumID и т. Д.) И ограничениями внешнего ключа в поле отношения один-много.

Но можем ли мы в этом случае включить форму наследования, чтобы избежать повторения одного и того же поля? Я говорю что-то в этом роде:

Table: EntityType(EntityTypeID, EntityName)
       This table would hold 3 entities (1. Artist, 2. Album, 3. Track)

Table: Entities(EntityID, Name, RelField, EntityTypeID)
       This table will hold the name of the entity (like the name of 
       an artist for example), the one-many field (foreign-key
       of EntityID) and EntityTypeID holding 1 for Artist, 2 for Album 
       and so on. 

---

Что вы думаете о вышеуказанном дизайне? Имеет ли смысл включать «концепции ООП» в этот сценарий БД?

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

.. кстати, если подумать, думаю, вы действительно можете проверить, соответствует ли введенное значение RelField of Artist альбому, возможно, с триггерами?

Answer 1

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

Answer 2

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

Я не думаю, что вы даже вероятно объедините эти сущности в своем обычном дизайне ОО.

Это напоминает мне (но незначительно) о попытке, которую я когда-то видел, реализовать все в одной таблице (с именем "Entity") с другой таблицей (с именем "Attributes") и таблицей соединений между ними.

Answer 3

Если вы занимаетесь такими вещами, посмотрите на наследование таблиц в PostgreSQL .

create table Artist (id integer not null primary key, name varchar(50));
create table Album (parent integer foreign key (id) references Artist) inherits (Artist);
create table Track (parent integer foreign key (id) references Album) inherits (Artist);

Answer 4

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

Тем не менее, я бы предпочел выбрать не-ООП способ и просто изменить схему в этом случае. Вот некоторые проблемы с решением ООП:

• что делать, если вы хотите добавить дату рождения художника?
• что если вы хотите сохранить длительность альбомов и треков?
• что если вы хотите сохранить тип трека?

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

Answer 5

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

Плюс, в какой-то момент вы захотите добавить атрибуты в одну категорию, которые не являются атрибутами для других. Объединение всех трех вместе не дает вам места для изменений, не вырывая фрагменты вашей системы.

Не будь таким умным, что ты запутался.

Answer 6

Я согласен с le dorfier, вы можете получить некоторое повторное использование понятия базовой сущности (ID, Name), но после этого понятия Artist, Album и Track будут расходиться.

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