[Moscow.pm] v2 просьба о ревью модуля DBIx::Struct

[Dmitry Simonov]

Как показал опыт, все эти заморочки с ORM имеют значение начиная с момента,
когда на сайте есть хоть какой-то биллинг. До этого момента не
заморачивайтесь и используйте, что хотите.

---
Dmitriy V. Simonov

15 января 2015 г., 19:19 пользователь Warstone на list.ru <warstone на list.ru>
написал:

> То есть сложных проектов, где есть "Ядро" и "Приложение", или
> гетерогенных, сервис-ориентированных приложений вы не писали? Хорошо... Вот
> вам пример из жизни...
>
> Есть Ядро, в ядре есть определение пользователя. Таблицы пользователя. Как
> будет использоваться пользователь и какие у него будут дополнительные поля
> определяется приложением.  Ядро заботится о "стандартных" полях. У
> пользователя есть аватар. В модели есть аксессор для урла на аватар. Ядро,
> зная что серверов много и выбирая какие сервера сейчас активны, на каких из
> них есть этот аватар и т.д. отдает Урл аватара. Для Приложения это просто
> аксессор.
>
> То что я описал - это один из примеров. Возможно не самый лучший. Но он
> дает представление о том, что ждут большие приложения от 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 <pef-secure на yandex.ru>:
>
>   On Thursday, January 15, 2015 16:39:40 Warstone на list.ru
> <https://e.mail.ru/compose?To=Warstone@list.ru> wrote:
> > Вообще есть 2 школы решения проблемы "Как работать с базой":
> > 1) Все в СУБД
> > 2) Все в Программе.
> > [...]
> > Мои разглагольствования сводятся к двум мыслям:
> > Голый SQL это плохо, если вы не умеете сахар на приложении.
> > "ORM должен уметь триггеры и много чего еще, чтобы им пользовались не
> только
> > вы". У вас оно есть?.. А стоит-ли начинать?
> >
> > Простите, если вбросил.
>
> Моя позиция примерно такая: в реальном приложении, обычно, заранее
> известно
> что за база будет использоваться, поэтому использование голого SQL вполне
> нормальное явление. Если приложение должно абстрагироваться от базы, то
> это,
> на мой взгляд, очень специальное приложение, которое должно как-то решить
> вопрос этой абстракции. Когда же мне приходится писать приложение, то база
> известна заранее. Мой модуль старается быть простым и понятным, т.е. это
> попытка свернуть "голый" SQL в перловые структуры данных и по записи
> всегда
> можно понять во что это развернётся в реальном SQL, кроме того, реальный
> SQL в
> модуле не отменяется. Тригеры у меня в БД, если нужны, как и хранимые
> процедуры. Т.е. между 1 и 2 я выбираю середину :)
> --
> PEF Developer
> --
> Moscow.pm mailing list
> moscow-pm на pm.org <https://e.mail.ru/compose?To=moscow%2dpm@pm.org> |
> http://moscow.pm.org
>
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150115/a61e8236/attachment.html>