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

Peter Rabbitson rabbit+moscowpm на rabbit.us
Чт Окт 27 10:22:19 PDT 2011


Господа! Зачем Вы травите?! ;)

Времени у меня в обрез, так что буду очен резким и кратким. Сначала отвечаю
на некоторые пункты:

> 1. построить качественный автогенератор SQL запросов на все случаи
> жизни (или по кр. мере на большинство) невозможно, поэтому его не
> стоит и пытаться сделать

FUD. С таким настроем ни PPI ни Moose и вообще много еще чего никогда бы не
появилось.

> Сильно лучше чем у DBIC. Запросы человек пишет много качественнее
> DBIC. Даже тупой человек.

и

> 3. Конструктор SQL-запросов крайне страшен. Работали мы с постоянно
> включенной отладкой (выводом всех делающихся запросов в лог). С одной
> стороны есть множество вещей которые на DBIC сделать крайне непросто
> (например многие аггрегаторные вещи), с другой стороны когда
> начинается работа с более чем двумя таблицами он зачастую мутит такие
> страшные вложенные SQL-запросы что волосы дыбом становятся, а с
> третьей стороны использование фич конкретной БД становится затруднено.

Я на 95% уверен что здесь проблема в недопонемании API. Запрос к самому
DBIC был сконструирован таким образом что без вложеных запросов достат
все просто невозможно. Осталные 5% - баги. Баги которые неимоверно трудно
исправить, потому что никто о них не долкадывает. Что приводит нас к
главной теме:

SHOW US THE CODE! :) По нескольку раз в год, в каком то углу интернета
поднимается вой что проект X тяжел, глуп, и вобще отстой. Попытки докопатся
"а в чем собственно дело" обычно заканчиваются печалным посылом на буквы
обеими сторонами. И так до следующего раза. Так что давайте конструктивнее,
а там видать все довольными останемся :)

Для начала - выложите search() с аргументами, и какой SQL был в результате
наворочен. Для дополнительного бонуса - предложите каким SQL можно бы было
все заменить.

Жду с нетерпением, ибо охота разделатся с проблемами и нашими и чужими :)

Cheers


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