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

StackOverflow https://stackoverflow.com/questions/728385

Вопрос

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

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

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

  • ИДЕНТИФИКАТОР
  • Имя
  • Внешнее отношение «один-многие» к соответствующим дочерним элементам (Исполнитель к альбому и Альбом к треку).

Типичным решением предоставленного решения будут три таблицы с одинаковыми полями (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 исполнителя альбому, может быть, с помощью триггеров?

Это было полезно?

Решение

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

Другие советы

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

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

Это напоминает мне (но лишь слегка) однажды увиденную мной попытку реализовать все в одной таблице (с именем «Сущность») с другой таблицей (с именем «Атрибуты») и связующей таблицей между ними.

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

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

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

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

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

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

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

Если вас интересуют подобные вещи, взгляните на наследование таблиц в 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);

Я согласен с Ле Дорфье, вы можете получить некоторое повторное использование понятия базовой сущности (идентификатор, имя), но после этого понятия «Исполнитель», «Альбом» и «Трек» будут расходиться.

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top