On Fri, Oct 28, 2011 at 12:32:58AM +0400, Ivan Petrov wrote: > > > Я (ясен пень) совершенно не согласен с приговором "нерешабельности" :) > > если кто решит эту задачу я буду его решение везде рекламировть ) > > только я сомневаюсь что в обозримое будущее это произойдет. > Я тоже верю в человечество: рано или поздно оно изобретет AI. но это > не при нас произойдет. не при ныне живущих. > > > Снова прошу - приведи конкретный пример. > > да пример типичный для любого бизнеса > > имеем группы пользователей > имеем задачи которые сваливаются на нескольких пользователей (может > свалиться на разных пользователей разных групп) > имеем индивидуальные статусы по каждой задаче у каждого пользователя > ну и этапы (подзадачи), которые сам пользователь может завести по > каждой задаче > > надо вывести такой отчетик по группе пользователей: > задача - параметры задачи - достиг ли кто статуса XXX > > > соответственно таблицы > группы - пользователи - отношение > задачи - отношение к пользователям - статусы > этапы - отношение к задачам - статусы > > DBIC тут такие ахтунги в SQL прорисовывал, что с этого и начали что > вернулись к SQL на котором написали один SELECT с одним GROUP BY и > двумя JOIN'ами. > > у DBIC проблема в том что он пытается разные объекты выбрать в разные > столбики. из за этого и получается ужоснах. >
Я не том спрашивал :( Как сказано в http://mail.pm.org/pipermail/moscow-pm/2011-October/010808.html > Для начала - выложите search() с аргументами, и какой SQL был в результате > наворочен. Для дополнительного бонуса - предложите каким SQL можно бы было > все заменить Все остальное пустой звук с извинением . -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
