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

[Alex Chistyakov]

2015-01-15 20:01 GMT+03:00 Dmitry Simonov <dsimonov на gmail.com>:
> Как показал опыт, все эти заморочки с ORM имеют значение начиная с момента,
> когда на сайте есть хоть какой-то биллинг. До этого момента не
> заморачивайтесь и используйте, что хотите.

Какой хитрый ответ!
Два раза прочитал, но так и не понял, когда есть биллинг - ORM все еще
нужен, или уже нет? :)

--
SY,
Alex



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