Как показал опыт, все эти заморочки с ORM имеют значение начиная с момента, когда на сайте есть хоть какой-то биллинг. До этого момента не заморачивайтесь и используйте, что хотите.
--- 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] > <https://e.mail.ru/[email protected]> wrote: > > Вообще есть 2 школы решения проблемы "Как работать с базой": > > 1) Все в СУБД > > 2) Все в Программе. > > [...] > > Мои разглагольствования сводятся к двум мыслям: > > Голый SQL это плохо, если вы не умеете сахар на приложении. > > "ORM должен уметь триггеры и много чего еще, чтобы им пользовались не > только > > вы". У вас оно есть?.. А стоит-ли начинать? > > > > Простите, если вбросил. > > Моя позиция примерно такая: в реальном приложении, обычно, заранее > известно > что за база будет использоваться, поэтому использование голого SQL вполне > нормальное явление. Если приложение должно абстрагироваться от базы, то > это, > на мой взгляд, очень специальное приложение, которое должно как-то решить > вопрос этой абстракции. Когда же мне приходится писать приложение, то база > известна заранее. Мой модуль старается быть простым и понятным, т.е. это > попытка свернуть "голый" SQL в перловые структуры данных и по записи > всегда > можно понять во что это развернётся в реальном SQL, кроме того, реальный > SQL в > модуле не отменяется. Тригеры у меня в БД, если нужны, как и хранимые > процедуры. Т.е. между 1 и 2 я выбираю середину :) > -- > PEF Developer > -- > Moscow.pm mailing list > [email protected] <https://e.mail.ru/compose?To=moscow%[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
