Это плохая практика использовать наследование в базе данных, чтобы сделать менее болезненным изменение последней схемы?

Question

Я думаю о новом дизайне для базы данных.И я хочу использовать Table-Per-Type наследование внутри базы данных.Я хочу отделить данные аудита (например, создать | изменить даты, user_id, разрешения и т. Д.) От фактических данных и использовать некоторые абстрактные объекты (таблицы), но я не планирую иметь более глубокое наследование, чем 3 (чтобы сделать вещи простыми и быстрыми)).Причины этого: я хочу, чтобы дизайн моей базы данных был гибким и легко изменяемым, без большого влияния на мой код.И использование наследования и расширение существующей функциональности таким образом выглядит для меня хорошим выбором.

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

Answer 1

Я хочу, чтобы дизайн моей базы данных был гибким и легко изменяемым, без большого влияния на мой код.

Сначала вы просто описываете объектно-реляционное сопоставление (ORM).Вам необходимо обновить свой вопрос, указав язык, базу данных и ORM.

Во-вторых, подобная гибкость часто доставляет неприятности.

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

База данных SQL имеет относительно фиксированную, не совсем гибкую схему, поэтому она может быть быстрой.

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

Более важно, однако, что не существует простого отображения унаследованных атрибутов в таблицы базы данных.

В некоторых случаях атрибуты суперкласса должны быть скопированы в несколько таблиц.

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

Когда вы узнаете больше об ORM, вы увидите, что это проблема нетривиальной сложности.Это требует обдумывания, и каждое проектное решение имеет важные последствия.

Не существует «общего» решения.Ваше смутное «И я хочу использовать Table-Per-Type наследование внутри базы данных» не является хорошей или плохой идеей.Это смутная идея.Каждая отдельная таблица и каждое отдельное решение о наследовании должны приниматься индивидуально, исходя из требований к производительности и ожидаемой потребности в гибкости.

Answer 2

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