2015-01-15 16:39 GMT+03:00 [email protected] <[email protected]>: > Вообще есть 2 школы решения проблемы "Как работать с базой": > 1) Все в СУБД > 2) Все в Программе. > > Суть проблемы (Зачем вообще появились ORM монстры типа DBIx::Class, я не > говорю об основной причине появления ORM, которая в названии кроется): > СУБД существует много. Если вы пишете код, который вы будете выкладывать в > паблик, то он должен мочь работать с несколькими СУБД. Сейчас это > PostgreSQL, MySQL, для мажоров - Oracle и более нестандартные СУБД типа > MSSQL. > Если перекладывать бизнес логику на СУБД, то для многобазия будет много > различного кода для каждой СУБД. Решение - перенести логику в ORM. > Отсюда появляется необходимость иметь возможность писать "триггеры" в > объектах ORM. > При всем том, что, казалось-бы, эта возможность - не причина появления ORM, > она одна из основных. > > Фактически, при всех минусах DBiX::Class (один из которых вы неявно > упомянули), она позволяет писать 1 код на много СУБД (с ограничениями, > конечно) и переносить бизнес-логику в приложение. Ведь далеко не все СУБД > могут из коробки горизонтально масштабироваться.
Огласите весь список тех реляционных СУБД, которые могут. > Для MySQL - это, платный, > насколько я помню, MySQL Cluster. MySQL Cluster - это средство горизонтального масштабирования? Ооооокей. > Для PostgreSQL - это PostgreSQL-XC, > который появился очень недавно и пока страшновато его использовать. Для > платных СУБД - это "много денег за то что вы это будете использовать". > Отсюда - перенос бизнес логики в приложение разгружает СУБД То есть, если мы перенесем в приложение ВСЮ бизнес-логику, СУБД работы не останется? O_O > и, если мы > говорим о ХайЛоаде, то перенос логики в приложение, позволяет решить > проблему хайлоада "докидыванием серверов в стойку", до следующего боттлнека, > который опять будет в СУБД, скорее всего, но на других нагрузках. Очень интересно. То есть: была у нас CPU-bound задача на СУБД (на СУБД!!!), мы перенесли ее на приложение, после чего уже на других нагрузках боттлнек у нас опять будет в СУБД. Вопрос номер один: а чего ж мы просто не взяли, я не знаю, master-slave репликацию? CPU-bound приложения легко масштабируются на любом конце многозвенной архитектуры. Вопрос номер два: а почему следующий боттлнек наступит на других нагрузках, а не на этих же? Нет никаких оснований так полагать. -- SY, Alex > А как > известно, при увеличении нагрузки можно найти нестандартное решение, которое > опять-таки снимет проблемы боттлнека. > > Мои разглагольствования сводятся к двум мыслям: > Голый 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 > -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
