То есть сложных проектов, где есть "Ядро" и "Приложение", или гетерогенных, сервис-ориентированных приложений вы не писали? Хорошо... Вот вам пример из жизни...
Есть Ядро, в ядре есть определение пользователя. Таблицы пользователя. Как будет использоваться пользователь и какие у него будут дополнительные поля определяется приложением. Ядро заботится о "стандартных" полях. У пользователя есть аватар. В модели есть аксессор для урла на аватар. Ядро, зная что серверов много и выбирая какие сервера сейчас активны, на каких из них есть этот аватар и т.д. отдает Урл аватара. Для Приложения это просто аксессор. То что я описал - это один из примеров. Возможно не самый лучший. Но он дает представление о том, что ждут большие приложения от 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
