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

[Warstone@list.ru]

 Thu, 15 Jan 2015 18:16:21 +0100 от PEF Secure <pef-secure на yandex.ru>:
>Придумывание чужих профилей самостоятельно -- это такое завуалированное 
>оскорбление? 
Нет, конечно, что-вы.
>Мне не удаётся увидеть в этом проблему, связанную с обсуждаемым модулем. Речь 
>идёт о доступе к базе данных. Какие поля есть у пользователя -- определяется 
>динамически в момент коннекта к базе или вызовом метода populate(), который 
>заново может перечитать структуру базы. Ну просто обычно это делается так: 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).
>В моём представлении, тут уже есть некоторая смесь понятий ORM и логики ядра. 
>Ядро спросили URL, оно ответило. Откуда оно его взяло, какими модулями 
>пользовалось -- совсем не важно. Для ядра у меня есть другой фреймворк, в 
>котором _возможно_ использовать DBIx::Struct, он (другой фреймворк) не готов к 
>публичному релизу и я его пока не намереваюсь обсуждать.  Только для приложения - пользователь - это данные. И с этими данным оно пойдет в модель, которая ORM (зачем 100500 модулей городить? Больше пакетов богу пакетов?)
>В самом первом сообщении я сразу определил, что модуль не пытается строить из 
>себя настоящую ORM, но обладает её некоторыми чертами. Все "сложные" случаи 
>оставлены "настоящему" SQL, который, на мой взгляд, куда понятнее и проще 
>поддаётся отладке.
Сложные варианты действительно проще делать на чистом SQL'е понимая чем это грозит. Допустим аналитики у нас имеют доступ к базе и сами строят SQL запросы. На мой взгляд - сложный вариант, это когда PostgreSQL включает GEQO.
>Правда. Никто не застрахован от "странных" случаев. Мне приходилось работать 
>одновременно с PostgreSQL и MySQL, но вторая база только для "специальных" 
>случаев, там можно просто DBIx::Connector как есть использовать. Действительно в данном случае так оказалось быстрее. Использовать MySQL как Key-Value (Холивар монгистов, давайте опустим, не об этом)
>Ну ясно дело, узко -- это мой удел, я понял. Да не в этом дело, право слово... В SQL::Abstract думали еще и о том, что это должно выполняться на как можно большем количестве диалектов, допустим., а потому некоторые конструкции получаются странные.
>Чем больше нагрузка на базу, тем сильнее надо думать о кешировании данных. Это 
>выходит за рамки модуля. Хранимые процедуры, наоборот, за счёт более близкого 
>доступа к данным дают выше пропускную способность базы, с тригерами тоже надо 
>быть аккуратными, но в правильных случаях они не мешают и помогают сохранить 
>логическую стркутуру базы. Ну... А за рамки ORM не выходит, ИМХО. И кешировать не все и не всегда получается. Хранимки дают большую скорость очень редко. У Pg в 99,9% узкое место - скорость доступа к диску.
>Вобщем, про боттлнек в базе _тут_ не понял. База одна и она медленная. Беков много и пофиг что они медленные, их много. Так понятнее?
>Так, давайте по порядку, что же мне нужно. Я согласен, что _глобально_, я даже 
>слова такого знать не хотел бы. Но постоянное писание одних и тех же 
>простейших 
>
>$row = $dbh->selectrow_hashref('select * from user where login = ? and 
>password = ?', undef, $login, $password) 
>
>за много лет задолбало. В итоге оно постепенно вылилось в то, что при коннекте 
>получается структура таблиц, между ними строятся связи, по этим связям можно 
>создавать упрощённые запросы:
>
>$row = one_row([article => -join => 'author'],{id_article => $id_article}) 
>
>в объекте $row будет разбирая на поля выборка 
>
>select * from article join author on (article.id_author = author.id) where 
>id_article = ?
>
>Получилось у меня привести это к чисто перловым структурам данных? Мне 
>кажется, вполне. 
>
>Абстрагировался ли я от конкретной БД? Ну почти, реальные тесты делал только 
>на PostgreSQL, предусмотрел пару моментов по майскл и склайт, но их не 
>тестировал за неимением. 
>
>Стало ли это выглядеть лучше, чем было? Ну мне так больше нравится. 
Посмотрите в сторону DBIx::Simple в связке с SQL::Abstract я думаю вас это удовлетворит, так как это оно и есть.
>Максимально допустимая нагрузка определяется множеством факторов. Как по мне, 
>модуль DBIx::Struct вряд ли будет тормозом. Даже скорее наоборот, расход 
>памяти для хранения данных ниже, чем когда строка результата выборки 
>представлена хешем. Грубое тестирование не выявило разницы с чистым DBI. Я говорил это в разрезе "Не используйте хранимки, переносите логику на приложение. Беков много, база одна".

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