2015-01-15 20:01 GMT+03:00 Dmitry Simonov <[email protected]>: > Как показал опыт, все эти заморочки с ORM имеют значение начиная с момента, > когда на сайте есть хоть какой-то биллинг. До этого момента не > заморачивайтесь и используйте, что хотите.
Какой хитрый ответ! Два раза прочитал, но так и не понял, когда есть биллинг - ORM все еще нужен, или уже нет? :) -- SY, Alex > > --- > Dmitriy V. Simonov > > 15 января 2015 г., 19:19 пользователь [email protected] <[email protected]> > написал: > >> То есть сложных проектов, где есть "Ядро" и "Приложение", или >> гетерогенных, сервис-ориентированных приложений вы не писали? Хорошо... Вот >> вам пример из жизни... >> >> Есть Ядро, в ядре есть определение пользователя. Таблицы пользователя. Как >> будет использоваться пользователь и какие у него будут дополнительные поля >> определяется приложением. Ядро заботится о "стандартных" полях. У >> пользователя есть аватар. В модели есть аксессор для урла на аватар. Ядро, >> зная что серверов много и выбирая какие сервера сейчас активны, на каких из >> них есть этот аватар и т.д. отдает Урл аватара. Для Приложения это просто >> аксессор. >> >> То что я описал - это один из примеров. Возможно не самый лучший. Но он >> дает представление о том, что ждут большие приложения от ORM'а. Если вы >> сможете поддержать ORM, когда я, написав сложный SQL запрос с аггрегатами и >> оконными процедурами в результате получив пользователя , получу урл на >> аватар, прогнанный через мой аксессор, не указывая что это пользователь (то >> есть ORM сам должен понять - откуда это взялось и что надо сделать с >> полями), то можно начинать разговаривать про ваш ORM. До этих пор большого >> смысла использовать его в "продакшене" я не вижу. Проблема в том, что я >> плохо представляю как этого добиться, не указывая очень много дополнительной >> информации при каждом запросе. Хотя вру... Для PostgreSQL - знаю как. Но >> только для него. >> >> Теперь более детально: >> > в реальном приложении, обычно, заранее известно >> что за база будет использоваться >> Согласен. Хотя у нас используются сразу 2 СУБД: PostgreSQL и MySQL. Такой >> вариант немного сбивает с толку, правда? >> >> > поэтому использование голого SQL вполне >> нормальное явление >> Это не следует из вышенаписанного по причинам, изложенным выше. >> >> > Если приложение должно абстрагироваться от базы, то это, >> на мой взгляд, очень специальное приложение, которое должно как-то решить >> вопрос этой абстракции. >> Для этого и существуют ORM. ORM (Object Relationship Mapping) и есть эта >> абстракция и именно об абстракции мы и говорим. >> >> > Мой модуль старается быть простым и понятным, т.е. это >> попытка свернуть "голый" SQL в перловые структуры данных и по записи >> всегда >> можно понять во что это развернётся в реальном SQL >> SQL::Abstract для этого и придумали. Не только для этого, конечно. Они не >> мыслили так узко. >> >> > Тригеры у меня в БД, если нужны, как и хранимые >> процедуры. >> Вы на этапе архитектуры подписались на то, что у вас не будет высокой >> нагрузки, так как иначе будет боттлек в базе. И чем больше логики вы будете >> класть в базу (а вы будете это делать, по причинам вышеописанным) тем вам >> будет потом больнее это переделывать. >> >> Вы между первым и 2м выбрали первое. Вам не нужен ORM вообще. И приложение >> не проектируется под большую нагрузку. Как следствие такой подход не >> генерирует большого интереса к себе, так как перл - это веб в большинстве >> случаев, а веб это хайлоад. >> Кстати вы это могли увидеть при первом сообщении в рассылку, которое было >> где-то месяц назад. >> >> Thu, 15 Jan 2015 15:37:11 +0100 от PEF Secure <[email protected]>: >> >> On Thursday, January 15, 2015 16:39:40 [email protected] wrote: >> > Вообще есть 2 школы решения проблемы "Как работать с базой": >> > 1) Все в СУБД >> > 2) Все в Программе. >> > [...] >> > Мои разглагольствования сводятся к двум мыслям: >> > Голый SQL это плохо, если вы не умеете сахар на приложении. >> > "ORM должен уметь триггеры и много чего еще, чтобы им пользовались не >> > только >> > вы". У вас оно есть?.. А стоит-ли начинать? >> > >> > Простите, если вбросил. >> >> Моя позиция примерно такая: в реальном приложении, обычно, заранее >> известно >> что за база будет использоваться, поэтому использование голого SQL вполне >> нормальное явление. Если приложение должно абстрагироваться от базы, то >> это, >> на мой взгляд, очень специальное приложение, которое должно как-то решить >> вопрос этой абстракции. Когда же мне приходится писать приложение, то база >> известна заранее. Мой модуль старается быть простым и понятным, т.е. это >> попытка свернуть "голый" SQL в перловые структуры данных и по записи >> всегда >> можно понять во что это развернётся в реальном SQL, кроме того, реальный >> SQL в >> модуле не отменяется. Тригеры у меня в БД, если нужны, как и хранимые >> процедуры. Т.е. между 1 и 2 я выбираю середину :) >> -- >> PEF Developer >> -- >> Moscow.pm mailing list >> [email protected] | http://moscow.pm.org >> >> >> >> -- >> Moscow.pm mailing list >> [email protected] | http://moscow.pm.org >> > > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org > -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
