<div dir="ltr">Как показал опыт, все эти заморочки с ORM имеют значение начиная с момента, когда на сайте есть хоть какой-то биллинг. До этого момента не заморачивайтесь и используйте, что хотите.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">---<br>Dmitriy V. Simonov</div></div></div>
<br><div class="gmail_quote">15 января 2015 г., 19:19 пользователь <a href="mailto:Warstone@list.ru">Warstone@list.ru</a> <span dir="ltr"><<a href="mailto:warstone@list.ru" target="_blank">warstone@list.ru</a>></span> написал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>То есть сложных проектов, где есть "Ядро" и "Приложение", или гетерогенных, сервис-ориентированных приложений вы не писали? Хорошо... Вот вам пример из жизни...<br><br>Есть Ядро, в ядре есть определение пользователя. Таблицы пользователя. Как будет использоваться пользователь и какие у него будут дополнительные поля определяется приложением. Ядро заботится о "стандартных" полях. У пользователя есть аватар. В модели есть аксессор для урла на аватар. Ядро, зная что серверов много и выбирая какие сервера сейчас активны, на каких из них есть этот аватар и т.д. отдает Урл аватара. Для Приложения это просто аксессор.<br><br>То что я описал - это один из примеров. Возможно не самый лучший. Но он дает представление о том, что ждут большие приложения от ORM'а. Если вы сможете поддержать ORM, когда я, написав сложный SQL запрос с аггрегатами и оконными процедурами в результате получив пользователя , получу урл на аватар, прогнанный через мой аксессор, не указывая что это пользователь (то есть ORM сам должен понять - откуда это взялось и что надо сделать с полями), то можно начинать разговаривать про ваш ORM. До этих пор большого смысла использовать его в "продакшене" я не вижу. Проблема в том, что я плохо представляю как этого добиться, не указывая очень много дополнительной информации при каждом запросе. Хотя вру... Для PostgreSQL - знаю как. Но только для него.<br><br>Теперь более детально:<span class=""><br>> в реальном приложении, обычно, заранее известно <br> что за база будет использоваться<br></span>Согласен. Хотя у нас используются сразу 2 СУБД: PostgreSQL и MySQL. Такой вариант немного сбивает с толку, правда?<span class=""><br><br>> поэтому использование голого SQL вполне <br> нормальное явление<br></span>Это не следует из вышенаписанного по причинам, изложенным выше.<span class=""><br><br>> Если приложение должно абстрагироваться от базы, то это, <br> на мой взгляд, очень специальное приложение, которое должно как-то решить <br> вопрос этой абстракции.<br></span>Для этого и существуют ORM. ORM (Object Relationship Mapping) и есть эта абстракция и именно об абстракции мы и говорим.<span class=""><br><br>> Мой модуль старается быть простым и понятным, т.е. это <br> попытка свернуть "голый" SQL в перловые структуры данных и по записи всегда <br> можно понять во что это развернётся в реальном SQL<br></span>SQL::Abstract для этого и придумали. Не только для этого, конечно. Они не мыслили так узко.<span class=""><br><br>> Тригеры у меня в БД, если нужны, как и хранимые <br> процедуры.<br></span>Вы на этапе архитектуры подписались на то, что у вас не будет высокой нагрузки, так как иначе будет боттлек в базе. И чем больше логики вы будете класть в базу (а вы будете это делать, по причинам вышеописанным) тем вам будет потом больнее это переделывать.<br><br>Вы между первым и 2м выбрали первое. Вам не нужен ORM вообще. И приложение не проектируется под большую нагрузку. Как следствие такой подход не генерирует большого интереса к себе, так как перл - это веб в большинстве случаев, а веб это хайлоад.<br>Кстати вы это могли увидеть при первом сообщении в рассылку, которое было где-то месяц назад.<br><br>Thu, 15 Jan 2015 15:37:11 +0100 от PEF Secure <<a href="mailto:pef-secure@yandex.ru" target="_blank">pef-secure@yandex.ru</a>>:<div><div class="h5"><br>
<blockquote style="border-left:1px solid #0857a6;margin:10px;padding:0 0 0 10px">
<div>
<div>
<div>
<div>On Thursday, January 15, 2015 16:39:40 <a href="https://e.mail.ru/compose?To=Warstone@list.ru" target="_blank">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="https://e.mail.ru/compose?To=moscow%2dpm@pm.org" target="_blank">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
</div>
</div>
</div>
</div>
</blockquote>
<br></div></div></div>
<br>--<br>
Moscow.pm mailing list<br>
<a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
<br></blockquote></div><br></div>