DB Design: Любите абстракцию или внешние ограничения?

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. 

---

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

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

По прилипаемости все три вместе, вы делаете ваши запросы менее readble (если вы затем разлагаете три категории в виде представлений), и вы затрудняете поиск и индексирование.

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

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

Answer 5

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

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

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

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

Answer 6

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