Подобие LINQ на PHP для EAV модели хранения данных

[morgen2009]

У Вас немножечко совсем не то. Это построитель SQL запроса, а не методы для обработки коллекций. К тому же посмотрите,
как бы просто писался Ваш запрос с использованием нативного LINQ

var r = objects.
     Where(o => o.ID_type == "object").
     GroupJoin(attributes, o => o.ID_objects, o => o.ID_objects, (o,u) => {
          return u.Select(u => u.value_big_int).toArray();
     });

или PHP (если бы эта библиотека уже умела конвертировать запрос в SQL)

$r = Linq::from($objects)
     ->where(Lambda::ID_type()->eq("object"))
     ->groupJoin($attributes, 'id_object', 'id_object')
     ->select(Lambda::v(1)->linq()->select('value_bigint')->toArray());

А по делу, посмотрите в направлении существующих ORM, тот же Doctrine. Мне кажется Вы пытаетесь сделать тоже самое.

[MadridianFox]

А я и не говорил, что это методы обработки коллекций. Я с самого начала написал, что здесь от LINQ используется только факт написания запроса на «родном» языке. И далее я говорю именно о генерации строки запроса. Даже само название основного класса говорит об этом — Query Builder.
И когда я его писал, я не пытался сделать его похожим на LINQ. Генератор запросов нужен чтобы упростить написание запросов.
что проще:

$r ->select(Lambda::v(1)->linq()->select('value_bigint')->toArray());

или

$q->select('attr');

?
С другой стороны, у меня написано о применении такого подхода к EAV. Умеет ваш Doctrine работать с EAV? Буду вам очень признателен, если подскажете мне ORM для EAV.

[morgen2009]

Мапить, чтобы работать в стиле,

$product->attributes["xxx"] = "yyy";

Doctrine пока еще не умеет (см. Limitations). Но можно классически задать отношения «class Product» — один-к-многим — «class AttributesValues» — многие-к-одному — «class Attribute» и тогда работать в стиле

foreach ($product->getAttributeValues() as $value) { if ($value->getAttribute()->getId() == 1) { ... } }

При этом будет работать и редактирование, и удаление, и добавление новых свойств. Думаю, Doctrine не одна такая ORM, но она одна из популярных.

[zloyusr]

А не могли бы вы поподробней рассказать почему на проектах выбрали именно EAV модель данных? Несколько раз приходилось сталкиваться с подобным, но осознать плюсов подхода так и не смог.

[MadridianFox]

В данном случае модель была выбрана, когда я ещё не участвовал в проекте.
Модель EAV имеет один плюс и много минусов, и очень важно сразу понять — так ли необходим этот плюс.
Достоинства EAV:
— Управление сущностями используя DML (Data Manipulation Language), а именно — создание и редактирование сущностей без использования операций CREATE TABLE и ALTER TABLE. При грамотном подходе это даёт поразительную гибкость базы данных.
Недостатки EAV:
— Относительно низкая скорость работы
— Каждый запрос несёт за собой большое количество рутинного кода для вытаскивания данных
— Относительно высокий порог вхождения специалистов
Таким образом EAV подходит для очень динамичных информационных систем, где скорость изменения структуры данных важнее скорости их получения.
Из личного опыта могу сказать, что эта модель бессмысленна, когда нет инструментов её обслуживания — редакторов сущностей, унифицированных компонентов информационной системы для отображения объекта/списка объектов, универсальных форм заполнения объектов и т.д. Ведь если для любого изменения приходится лезть в код, то почему не сделать это хотя-бы традиционно?

[zloyusr]

Спасибо за развернутый ответ. Вопрос в догонку: почему бы не решать вопрос структуры базы ее отсутствием, а именно не использовать доментоориентированные базы?

[MadridianFox]

Несмотря на то, что этот вопрос мне задаёт большинство людей, которые знают чем я занимаюсь, легче найти специалиста который хорошо разбирается в «традиционных» БД, чем человека который имеет опыт работы с документоориентированными базами данных. Ну а конкретно в этом случае, при проектировании ИС люди просто не знали о существовании таких БД.

[Kathy]

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