Thu, 15 Jan 2015 18:16:21 +0100 от PEF Secure <[email protected]>: >Придумывание чужих профилей самостоятельно -- это такое завуалированное >оскорбление? Нет, конечно, что-вы. >Мне не удаётся увидеть в этом проблему, связанную с обсуждаемым модулем. Речь >идёт о доступе к базе данных. Какие поля есть у пользователя -- определяется >динамически в момент коннекта к базе или вызовом метода 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. Я >говорил это в разрезе "Не используйте хранимки, переносите логику на >приложение. Беков много, база одна".
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
