Производительность больших систем схемы EAV/open на SQL Server

Независимо от SQL Server MS по сравнению с любым другим брендом базы данных худшая проблема производительности с EAV - то, что люди пытаются сделать запросы монстра для восстановления объекта на одной строке. Это требует отдельного соединения на атрибут.

SELECT e.id, a1.attr_value as "cost", a2.attr_value as "color",
  a3.attr_value as "size", . . .
FROM entity e
  LEFT OUTER JOIN attrib a1 ON (e.entity_id = a1.entity_id AND a1.attr_name = 'cost')
  LEFT OUTER JOIN attrib a2 ON (e.entity_id = a2.entity_id AND a2.attr_name = 'color')
  LEFT OUTER JOIN attrib a2 ON (e.entity_id = a3.entity_id AND a3.attr_name = 'size')
  . . . additional joins for each attribute . . .

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

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

SELECT e.id, a.attr_name, a.attr_value
FROM entity e JOIN attrib a USING (entity_id)
ORDER BY e.id;

Этот SQL-запрос настолько более прост и более эффективен, что он восполняет дополнительный код приложения.

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

Я не эксперт по EAV, но несколько более опытных разработчиков, чем я прокомментировал, что платформа электронной коммерции Magento с открытым исходным кодом является медленной, прежде всего, из-за архитектуры EAV через MySQL. Самый очевидный недостаток не может легко быть преодолен. Причем тот трудность, с которой это должно диагностировать, где и как информация представлена для объектов и значений атрибута как размер увеличений приложения. Второй аргумент против EAV, который я услышал, - то, что он требует соединений таблицы, которые входят в низкие двузначные цифры, но было прокомментировано, что использование InnoDB по MyISAM улучшило производительность некоторые (или это могло быть наоборот, но я не могу помнить полностью).