Реляционные данные: подходы наследования объектов.Лучшая практика

Question

Существует несколько подходов к хранению иерархии сущностей в базе данных отношений.

Например, есть сущность человека (20 основных атрибутов), сущность студента (такая же, как личность, но присутствует несколько новых определенных полей), сотрудник(то же самое, что и персона, но есть некоторые новые поля) и т. д.

Когда вы советуете использовать (а не использовать) следующие подходы к моделированию данных:

• Одна большая таблица со всемивозможные поля + поле маркера personType (студент или сотрудник)
• Наследование таблиц
• Одна таблица с полем XML (или, возможно, другой тип данных) для хранения всех настраиваемых полей
• Что-тоеще, но также и реляционные ...

Заранее спасибо!

Answer 1

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

person { person_id PK, name, dob, ... }
student { person_id PK FK(person.person_id), admission_id, year_started, ... }
employee { person_id PK FK(person.person_id), salary_bracket, ... }

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

Answer 2

Ознакомьтесь с документами по отображению наследования hibernate . Там вы найдете три общих подхода и список плюсов и минусов каждого.

Answer 3

Если вы используете ORM для реализации своих классов, инструменты ORM, которые вы используете, предоставят вам опции, как правило, две опции, одну таблицу класса один или один родительский класс одну таблицу и каждую таблицу для каждого дочернего класса. Я использую XPO от Devexpress.com, один фреймворк ORM. Он предлагает эти два варианта.

Если вы используете ORM, я боюсь, что нет других общих вариантов.

Ин