<HTML><BODY>То есть сложных проектов, где есть "Ядро" и "Приложение", или гетерогенных, сервис-ориентированных приложений вы не писали? Хорошо... Вот вам пример из жизни...<br><br>Есть Ядро, в ядре есть определение пользователя. Таблицы пользователя. Как будет использоваться пользователь и какие у него будут дополнительные поля определяется приложением. Ядро заботится о "стандартных" полях. У пользователя есть аватар. В модели есть аксессор для урла на аватар. Ядро, зная что серверов много и выбирая какие сервера сейчас активны, на каких из них есть этот аватар и т.д. отдает Урл аватара. Для Приложения это просто аксессор.<br><br>То что я описал - это один из примеров. Возможно не самый лучший. Но он дает представление о том, что ждут большие приложения от ORM'а. Если вы сможете поддержать ORM, когда я, написав сложный SQL запрос с аггрегатами и оконными процедурами в результате получив пользователя , получу урл на аватар, прогнанный через мой аксессор, не указывая что это пользователь (то есть ORM сам должен понять - откуда это взялось и что надо сделать с полями), то можно начинать разговаривать про ваш ORM. До этих пор большого смысла использовать его в "продакшене" я не вижу. Проблема в том, что я плохо представляю как этого добиться, не указывая очень много дополнительной информации при каждом запросе. Хотя вру... Для PostgreSQL - знаю как. Но только для него.<br><br>Теперь более детально:<br>> в реальном приложении, обычно, заранее известно <br> что за база будет использоваться<br>Согласен. Хотя у нас используются сразу 2 СУБД: PostgreSQL и MySQL. Такой вариант немного сбивает с толку, правда?<br><br>> поэтому использование голого SQL вполне <br> нормальное явление<br>Это не следует из вышенаписанного по причинам, изложенным выше.<br><br>> Если приложение должно абстрагироваться от базы, то это, <br> на мой взгляд, очень специальное приложение, которое должно как-то решить <br> вопрос этой абстракции.<br>Для этого и существуют ORM. ORM (Object Relationship Mapping) и есть эта абстракция и именно об абстракции мы и говорим.<br><br>> Мой модуль старается быть простым и понятным, т.е. это <br> попытка свернуть "голый" SQL в перловые структуры данных и по записи всегда <br> можно понять во что это развернётся в реальном SQL<br>SQL::Abstract для этого и придумали. Не только для этого, конечно. Они не мыслили так узко.<br><br>> Тригеры у меня в БД, если нужны, как и хранимые <br> процедуры.<br>Вы на этапе архитектуры подписались на то, что у вас не будет высокой нагрузки, так как иначе будет боттлек в базе. И чем больше логики вы будете класть в базу (а вы будете это делать, по причинам вышеописанным) тем вам будет потом больнее это переделывать.<br><br>Вы между первым и 2м выбрали первое. Вам не нужен ORM вообще. И приложение не проектируется под большую нагрузку. Как следствие такой подход не генерирует большого интереса к себе, так как перл - это веб в большинстве случаев, а веб это хайлоад.<br>Кстати вы это могли увидеть при первом сообщении в рассылку, которое было где-то месяц назад.<br><br>Thu, 15 Jan 2015 15:37:11 +0100 от PEF Secure <pef-secure@yandex.ru>:<br>
<blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">
<div id="">
<div class="js-helper js-readmsg-msg">
<style type="text/css"></style>
<div>
<base target="_self" href="https://e.mail.ru/">
<div id="style_14213327610000000064_BODY">On Thursday, January 15, 2015 16:39:40 <a href="/compose?To=Warstone@list.ru">Warstone@list.ru</a> wrote:<br>
> Вообще есть 2 школы решения проблемы "Как работать с базой":<br>
> 1) Все в СУБД<br>
> 2) Все в Программе.<br>
> [...]<br>
> Мои разглагольствования сводятся к двум мыслям:<br>
> Голый SQL это плохо, если вы не умеете сахар на приложении.<br>
> "ORM должен уметь триггеры и много чего еще, чтобы им пользовались не только<br>
> вы". У вас оно есть?.. А стоит-ли начинать?<br>
> <br>
> Простите, если вбросил.<br>
<br>
Моя позиция примерно такая: в реальном приложении, обычно, заранее известно <br>
что за база будет использоваться, поэтому использование голого SQL вполне <br>
нормальное явление. Если приложение должно абстрагироваться от базы, то это, <br>
на мой взгляд, очень специальное приложение, которое должно как-то решить <br>
вопрос этой абстракции. Когда же мне приходится писать приложение, то база <br>
известна заранее. Мой модуль старается быть простым и понятным, т.е. это <br>
попытка свернуть "голый" SQL в перловые структуры данных и по записи всегда <br>
можно понять во что это развернётся в реальном SQL, кроме того, реальный SQL в <br>
модуле не отменяется. Тригеры у меня в БД, если нужны, как и хранимые <br>
процедуры. Т.е. между 1 и 2 я выбираю середину :)<br>
-- <br>
PEF Developer<br>
-- <br>
Moscow.pm mailing list<br>
<a href="/compose?To=moscow%2dpm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
</div>
<base target="_self" href="https://e.mail.ru/">
</div>
</div>
</div>
</blockquote>
<br></BODY></HTML>