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