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

[PEF Secure]

On Thursday, January 15, 2015 21:46:04 Warstone на list.ru wrote:
> Ну просто
> обычно это делается так: UserRS->search({id => $uid})->single->avatar_url
> При всем при этом в User.pm (которое схема таблицы User) лежит что-то такое:
> sub avatar_url {
>     ...
>    my $candidates = _get_best_candidates_as_array;
>     return  $candidates->[random(scalar @$candidates)];
> }
> То есть вызов отдает разные данные, при том что само поле содержит только
> ссылку на картинку (которая не всегда должна совпадать с именем
> пользователя или его id).

В моём варианте можно унаследовать класс DBC::User и сделать то же самое. 
Пользовался подобным несколько раз, но, в основном, "всё иначе" и объекты БД 
не привожу к ООП (смеси данных из БД и произвольных методов), а определяю 
отдельный API работы с ядром, а что вернёт хендлер метода API уже дело 
хендлера.

>  Только для приложения - пользователь - это данные. И с этими
> данным оно пойдет в модель, которая ORM (зачем 100500 модулей городить?
> Больше пакетов богу пакетов?) 

Ни разу не наблюдал особой проблемы с количеством модулей. Ах, да, я ж, 
наверное, "не писал сложных проекто никогда". Возможно.

> Сложные варианты действительно проще делать на чистом SQL'е понимая чем это
> грозит. 

Да ничем, кроме некоторой негибкости кода, по моему мнению.

> Действительно в данном случае так оказалось быстрее.
> Использовать MySQL как Key-Value

Ой. И никакой ORM? 

> В SQL::Abstract думали еще и о том, что это должно
> выполняться на как можно большем количестве диалектов, допустим.

Ну да, поэтому работу с offset/limit решили не делать. SQL::Abstract. как ни 
странно, ничего не хочет знать про БД, он именно абстрактный "вычислитель 
запросов".


> Ну... А за рамки ORM не выходит, ИМХО. И кешировать не все
> и не всегда получается. Хранимки дают большую скорость очень редко. 

Зависит от ситуации. Хранимки выполняют две функции: поддержание некоторого 
API БД и исключение лишнего трафика клиент-сервер. Если сам запрос достаточно 
тяжёлый и лишнего трафика сервер-клиент нет, то хранимка особого выигрыша в 
производительности не даст, но некоторые алгоритмы там всё-таки разумнее 
реализовывать. Но, собственно, кому я рассказываю.

> База одна и она медленная. Беков много и пофиг что они
> медленные, их много. Так понятнее? 

Нет, так как раз запутаннее. Сначала надо всё-таки полную структуру 
подразумеваемого приложения понять. Фронт запрашивает ядро. Ядро обращается к 
бекенду. Бекенд обращается к базе. При этом объекты ORM выступают в роли 
бекенда (или ядра?). Я запутался.

Я признаюсь, ни разу не писал, когда бекендов много. Или когда баз данных 
много. У меня были проекты, когда несколько фронтов<->ядро+база, а проблема 
производительности базы решалась ростом RAM и переходом на SSD. Но, я 
чувствую, что это просто мелочь в сравнении с настоящим хайлоадом.

> Посмотрите в сторону DBIx::Simple в связке с SQL::Abstract я думаю вас это
> удовлетворит, так как это оно и есть.

Смотрел когда-то давно. Ну, допустим, я повторил даже чью-то функциональность. 
Но, как мне кажется, я сделал это удобнее. И зачем мне отказываться от того, 
что я написал в пользу других модулей? Например, в моём модуле есть следующий 
сахар (цитата из документации)

Допустим, у нас есть следующие таблицы:

employer:
    id_employer,
    name
  
 employee:
    id_employee,
    id_employer references employer (id_employer),
    id_employee_invited_by
    name

 alter table employee add constraint fk_employee_employee 
     foreign key (id_employee_invited_by) references employee (id_employee);

Тогда можно использовать следующие выражения:

 my $employee = one_row("employee", {name => 'John'});
 my $employer = $employee->Employer;

Последняя строка автоматически по ссылке из объекта $employee выберет объект 
$employer.

my $referenced_by = $employee->refEmployeeInvitedBys;

Эта строка выберет всех "employee", которые были рекомндованы конкретным  
$employee.

my $robert_associates = $employee->Employer->refEmployees(name => 'Robert');

А эта строка выберет коллег этого $employee, у кого имя 'Robert'.

Личто мне этот сахар удобен и экономит код. На счёт эффективности не вижу тут 
проблем так же.

-- 
PEF Developer