При разработке ORM, каков наилучший подход для представления отношений с точки зрения производительности?

Question

При разработке ORM, каков наилучший подход для представления отношений с точки зрения производительности? Я имею в виду, из следующих двух, какой подход лучше всего учитывает производительность?

class Employee
{
     int ID { get; set; }

     String Name { get; set; }

     int DepartmentID { get; set; } //This approach uses DepartmentID
}

--- ИЛИ ---

class Employee
{
     int ID { get; set; }

     String Name { get; set; }

     Department Department { get; set; } //This approach uses Department class 
}

С моей точки зрения, второй подход хорош. Это тоже объектно-ориентированный. И это должно быть главной целью ORM; преобразовать отношения из РСУБД в объектно-ориентированную. Но при этом мы должны были бы загрузить весь объект Отдела в объект сотрудника, даже если это не требуется.

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

Answer 1

Большинство каркасов ORM будут обрабатывать второй случай с эквивалентной производительностью первого случая. Взяв Hibernate в качестве эталонного примера, они недвусмысленно скажут вам, что вы никогда не сделаете первый вариант. Вообще-то, они как-то раздражены.

На самом деле, я считаю, что первый вариант технически не будет рассматриваться как ORM, поскольку отношения обрабатываются на уровне идентификатора в вашем коде ООП.

Hibernate (как и большинство других) загружается медленно, а это значит, что вы можете загрузить своего сотрудника, и он не будет загружать отдел. Но затем, если вы скажете employee.getDepartment (), в этот момент он сделает простой оператор выбора, чтобы получить данные отдела.

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

Ознакомьтесь с "Маленьким учебником по стратегии извлечения" в Hibernate * для получения дополнительной информации.

Answer 2

Вы забыли, что связанные элементы можно загружать лениво.

То есть, когда вы создаете объект Employee, вам не нужно заполнять поле Department. Это можно заполнить, когда вызывается метод доступа get.

Answer 3

это не такая большая разница в производительности, на самом деле проще реализовать одно, чем другое.