Наследование является одним из основных принципов ООП. В то же время, значительное количество корпоративных приложений имеют в своей основе реляционные базы данных 
 
 Главное противоречие между объектно-ориентированной и реляционной моделями заключается в том, объектная модель поддерживает два вида отношений («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