Наследование является одним из основных принципов ООП. В то же время, значительное количество корпоративных приложений имеют в своей основе реляционные базы данных
Главное противоречие между объектно-ориентированной и реляционной моделями заключается в том, объектная модель поддерживает два вида отношений («is a» — “является”, и «has a» — “имеет”), а модели, основанные на SQL, поддерживают только отношения «has a».
Иными словами, **SQL не понимает наследование типов и не поддерживает его**.
Поэтому на этапе построения сущностей и схемы БД одной из главных задач разработчика будет выбор оптимальной стратегии представления иерархии наследования.
Всего таких стратегий 4:
**1) **Использовать одну таблицу для каждого класса и полиморфное поведение по умолчанию.
**2)** Одна таблица для каждого конкретного класса, с полным исключением полиморфизма и отношений наследования из схемы SQL (для полиморфного поведения во время выполнения будут использоваться UNION-запросы)
**3)** Единая таблица для всей иерархии классов. Возможна только за счет денормализации схемы SQL. Определять суперкласс и подклассы будет возможно посредством различия строк.
**4)** Одна таблица для каждого подкласса, где отношение “is a” представлено в виде «has a», т.е. – связь по внешнему ключу с использованием JOIN.
Можно выделить 3 главных фактора, на которые повлияет выбранная вами стратегия:
**1)** Производительность (мы используем “hibernate\_show\_sql”, чтобы увидеть и оценить все выполняемые к БД запросы)
**2)** Нормализация схемы и гарантия целостности данных (не каждая стратегия гарантирует выполнение ограничения NOT NULL)
**3) **Возможность эволюции вашей схемы
Под катом каждая из этих стратегий будет рассмотрена подробно, с указанием преимуществ и недостатков, а также будут даны рекомендации по выбору стратегии в конкретных случаях.
[Читать дальше →][1]
[1]:
https://habrahabr.ru/post/337488/?utm_source=habrahabr&utm_medium=rss&utm_campaign=feed_posts#habracut