[Moscow.pm] Размышления на тему ORM и вообще работы с БД

Ivan Petrov i.petro.77.00 на gmail.com
Чт Окт 27 13:32:58 PDT 2011


> Я (ясен пень) совершенно не согласен с приговором "нерешабельности" :)

если кто решит эту задачу я буду его решение везде рекламировть )

только я сомневаюсь что в обозримое будущее это произойдет.
Я тоже верю в человечество: рано или поздно оно изобретет AI. но это
не при нас произойдет. не при ныне живущих.

> Снова прошу - приведи конкретный пример.

да пример типичный для любого бизнеса

имеем группы пользователей
имеем задачи которые сваливаются на нескольких пользователей (может
свалиться на разных пользователей разных групп)
имеем индивидуальные статусы по каждой задаче у каждого пользователя
ну и этапы (подзадачи), которые сам пользователь может завести по
каждой задаче

надо вывести такой отчетик по группе пользователей:
задача - параметры задачи - достиг ли кто статуса XXX


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

DBIC тут такие ахтунги в SQL прорисовывал, что с этого и начали что
вернулись к SQL на котором написали один SELECT с одним GROUP BY и
двумя JOIN'ами.

у DBIC проблема в том что он пытается разные объекты выбрать в разные
столбики. из за этого и получается ужоснах.

ну уж не говоря о простом:

имеем объект

user

у него есть отношение

task


$user->task->delete;

далее
$user->is_changed == 0
$user->in_storage == 1

отношения между объектами, говорите? где они? 
ладно бы они были реализованы


Подробная информация о списке рассылки Moscow-pm