Вообще есть 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 <[email protected]>: >Приветствую! > >Есть желание опубликовать на 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 >[email protected] | http://moscow.pm.org
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
