<HTML><BODY>Thu, 15 Jan 2015 18:16:21 +0100 от PEF Secure <pef-secure@yandex.ru>:<br>
<blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213422070000000196_BODY">Придумывание чужих профилей самостоятельно -- это такое завуалированное <br>
оскорбление? <br></div></div></div></div></blockquote>Нет, конечно, что-вы.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213422070000000196_BODY">Мне не удаётся увидеть в этом проблему, связанную с обсуждаемым модулем. Речь <br>
идёт о доступе к базе данных. Какие поля есть у пользователя -- определяется <br>
динамически в момент коннекта к базе или вызовом метода populate(), который <br>
заново может перечитать структуру базы.</div></div></div></div></blockquote>Ну просто обычно это делается так: UserRS->search({id => $uid})->single->avatar_url<br>При всем при этом в User.pm (которое схема таблицы User) лежит что-то такое:<br>sub avatar_url {<br> ...<br> my $candidates = _get_best_candidates_as_array;<br> return $candidates->[random(scalar @$candidates)]; <br>}<br>То есть вызов отдает разные данные, при том что само поле содержит только ссылку на картинку (которая не всегда должна совпадать с именем пользователя или его id).<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213422070000000196_BODY">В моём представлении, тут уже есть некоторая смесь понятий ORM и логики ядра. <br>
Ядро спросили URL, оно ответило. Откуда оно его взяло, какими модулями <br>
пользовалось -- совсем не важно. Для ядра у меня есть другой фреймворк, в <br>
котором _возможно_ использовать DBIx::Struct, он (другой фреймворк) не готов к <br>
публичному релизу и я его пока не намереваюсь обсуждать. </div></div></div></div></blockquote>Только для приложения - пользователь - это данные. И с этими данным оно пойдет в модель, которая ORM (зачем 100500 модулей городить? Больше пакетов богу пакетов?)<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213422070000000196_BODY">В самом первом сообщении я сразу определил, что модуль не пытается строить из <br>
себя настоящую ORM, но обладает её некоторыми чертами. Все "сложные" случаи <br>
оставлены "настоящему" SQL, который, на мой взгляд, куда понятнее и проще <br>
поддаётся отладке.<br></div></div></div></div></blockquote>Сложные варианты действительно проще делать на чистом SQL'е понимая чем это грозит. Допустим аналитики у нас имеют доступ к базе и сами строят SQL запросы. На мой взгляд - сложный вариант, это когда PostgreSQL включает GEQO.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213422070000000196_BODY">Правда. Никто не застрахован от "странных" случаев. Мне приходилось работать <br>
одновременно с PostgreSQL и MySQL, но вторая база только для "специальных" <br>
случаев, там можно просто DBIx::Connector как есть использовать.</div></div></div></div></blockquote>Действительно в данном случае так оказалось быстрее. Использовать MySQL как Key-Value (Холивар монгистов, давайте опустим, не об этом)<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213422070000000196_BODY">Ну ясно дело, узко -- это мой удел, я понял.</div></div></div></div></blockquote>Да не в этом дело, право слово... В SQL::Abstract думали еще и о том, что это должно выполняться на как можно большем количестве диалектов, допустим., а потому некоторые конструкции получаются странные.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213422070000000196_BODY">Чем больше нагрузка на базу, тем сильнее надо думать о кешировании данных. Это <br>
выходит за рамки модуля. Хранимые процедуры, наоборот, за счёт более близкого <br>
доступа к данным дают выше пропускную способность базы, с тригерами тоже надо <br>
быть аккуратными, но в правильных случаях они не мешают и помогают сохранить <br>
логическую стркутуру базы.</div></div></div></div></blockquote>Ну... А за рамки ORM не выходит, ИМХО. И кешировать не все и не всегда получается. Хранимки дают большую скорость очень редко. У Pg в 99,9% узкое место - скорость доступа к диску.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213422070000000196_BODY">Вобщем, про боттлнек в базе _тут_ не понял.</div></div></div></div></blockquote>База одна и она медленная. Беков много и пофиг что они медленные, их много. Так понятнее?<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213422070000000196_BODY">Так, давайте по порядку, что же мне нужно. Я согласен, что _глобально_, я даже <br>
слова такого знать не хотел бы. Но постоянное писание одних и тех же <br>
простейших <br><br>
$row = $dbh->selectrow_hashref('select * from user where login = ? and <br>
password = ?', undef, $login, $password) <br><br>
за много лет задолбало. В итоге оно постепенно вылилось в то, что при коннекте <br>
получается структура таблиц, между ними строятся связи, по этим связям можно <br>
создавать упрощённые запросы:<br><br>
$row = one_row([article => -join => 'author'],{id_article => $id_article}) <br><br>
в объекте $row будет разбирая на поля выборка <br><br>
select * from article join author on (article.id_author = author.id) where <br>
id_article = ?<br><br>
Получилось у меня привести это к чисто перловым структурам данных? Мне <br>
кажется, вполне. <br><br>
Абстрагировался ли я от конкретной БД? Ну почти, реальные тесты делал только <br>
на PostgreSQL, предусмотрел пару моментов по майскл и склайт, но их не <br>
тестировал за неимением. <br><br>
Стало ли это выглядеть лучше, чем было? Ну мне так больше нравится. <br></div></div></div></div></blockquote>Посмотрите в сторону DBIx::Simple в связке с SQL::Abstract я думаю вас это удовлетворит, так как это оно и есть.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213422070000000196_BODY">Максимально допустимая нагрузка определяется множеством факторов. Как по мне, <br>
модуль DBIx::Struct вряд ли будет тормозом. Даже скорее наоборот, расход <br>
памяти для хранения данных ниже, чем когда строка результата выборки <br>
представлена хешем. Грубое тестирование не выявило разницы с чистым DBI.</div></div></div></div></blockquote>Я говорил это в разрезе "Не используйте хранимки, переносите логику на приложение. Беков много, база одна".<br><br id="style_14213422070000000196_BODY"></BODY></HTML>