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

[Alex Chistyakov]

2015-01-15 16:39 GMT+03:00 Warstone на list.ru <warstone на list.ru>:
> Вообще есть 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 <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
>
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>