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

[Warstone@list.ru]

 Вообще есть 2 школы решения проблемы "Как работать с базой":
1) Все в СУБД
2) Все в Программе.

Суть проблемы (Зачем вообще появились ORM монстры типа DBIx::Class, я не говорю об основной причине появления ORM, которая в названии кроется):
СУБД существует много. Если вы пишете код, который вы будете выкладывать в паблик, то он должен мочь работать с несколькими СУБД. Сейчас это PostgreSQL, MySQL, для мажоров - Oracle и более нестандартные СУБД типа MSSQL.
Если перекладывать бизнес логику на СУБД, то для многобазия будет много различного кода для каждой СУБД. Решение - перенести логику в ORM.
Отсюда появляется необходимость иметь возможность писать "триггеры" в объектах ORM.
При всем том, что, казалось-бы, эта возможность - не причина появления ORM, она одна из основных.

Фактически, при всех минусах DBiX::Class (один из которых вы неявно упомянули), она позволяет писать 1 код на много СУБД (с ограничениями, конечно) и переносить бизнес-логику в приложение. Ведь далеко не все СУБД могут из коробки горизонтально масштабироваться. Для MySQL - это, платный, насколько я помню, MySQL Cluster. Для PostgreSQL - это PostgreSQL-XC, который появился очень недавно и пока страшновато его использовать. Для платных СУБД - это "много денег за то что вы это будете использовать". Отсюда - перенос бизнес логики в приложение разгружает СУБД и, если мы говорим о ХайЛоаде, то перенос логики в приложение, позволяет решить проблему хайлоада "докидыванием серверов в стойку", до следующего боттлнека, который опять будет в СУБД, скорее всего, но на других нагрузках. А как известно, при увеличении нагрузки можно найти нестандартное решение, которое опять-таки снимет проблемы боттлнека.

Мои разглагольствования сводятся к двум мыслям:
Голый SQL это плохо, если вы не умеете сахар на приложении.
"ORM должен уметь триггеры и много чего еще, чтобы им пользовались не только вы". У вас оно есть?.. А стоит-ли начинать?

Простите, если вбросил.

Wed, 14 Jan 2015 19:37:29 +0100 от PEF Secure <pef-secure на yandex.ru>:
>Приветствую!
>
>Есть желание опубликовать на CPAN свой модуль, этакий вариант недо-ORM. Моё 
>мнение, что все навороты ORM полезны, пока они упрощают код или дают ещё какие 
>плюсы, но если пользование ORM превращается в спорт, то это уже как-то не 
>здорово. Прочтение статьи  http://pragmaticperl.com/issues/22/pragmaticperl-22-dbixclass.-%D1%81%D0%B1%D0%BE%D1%80%D0%BD%D0%B8%D0%BA-%D1%80%D0%B5%D1%86%D0%B5%D0%BF%D1%82%D0%BE%D0%B2.html
>убеждает лично меня в том, что чистый SQL часто сильно проще понимать и 
>использовать. Тем не менее, чистый SQL часто не настолько уж "чист": код 
>приходится собирать по каким-то внешним условиям, иногда условия становятся 
>уже сложно подчинённые, тогда на помощь приходит SQL::Abstract. Постепенно с 
>использованием этого модуля у меня родился свой:  https://github.com/pef-secure/dbix-struct -- ревью его кода, а так же любым комментариям буду 
>признателен. 
>
>Существует _демонстрационный_ проект, в котором этот модуль использован в 
>основе операций CRUD: 
>https://github.com/pef-secure/pef-front-demo/blob/master/app/Demo/Local/Article.pm . В остальных модулях тоже 
>встречается использование, этот самый показательный. Структура демо приложения 
>тут:  https://github.com/pef-secure/pef-front-demo/blob/master/demo.sql
>
>-- 
>PEF Developer
>-- 
>Moscow.pm mailing list
>moscow-pm на pm.org |  http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150115/1d286825/attachment.html>