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

[Alex Chistyakov]

2015-01-15 22:44 GMT+03:00 Ivan Petrov <i.petro.77.00 на gmail.com>:
>
>> Мои разглагольствования сводятся к двум мыслям:
>> Голый SQL это плохо, если вы не умеете сахар на приложении.
>
> мне кажется голый SQL это единственный способ строить нормальные
> хайлоады.
> как показывает практика ВСЕ кластерные решения (шардинг и проч) - вещи
> ОЧЕНЬ интимные.
>
> то есть например если у вас пользователи, то вам пойдет практически
> любой вид шардинга, а если у вас таблицы с логами действий тех же
> пользователей и вам надо выводить списки, то уже далеко не любой
> подойдет.

Хранить time-series data в RDBMS, да еще и с шардами - какая свежая
идея, однако!


>
> далее, раз уж эту тему обсуждать далее.
> я считаю что попытка делать приложение "переносимым между БД" ничего
> удобного кроме тестов не дает.
> ну только что тесты вы сможете делать на SQLLite, тогда как на боевом
> у вас будет скажем Pg/MySQL.
> но вопрос поднять тестовую Pg базу для проекта - несложный и я не вижу
> в этом преимущества.
>
> а далее начинается.
> ну MySQL, как БД - полное говно, это понятно.
> если говорить о Pg, то там например полно синтаксиса который можно
> использовать для оптимизации скорости работы.
>
> SELECT
>     *
> FROM
>     table1
> JOIN
>     table2
> JOIN
>     table3
> WHERE
>     table1.col = 10
>
> до сих пор многие базы не научились нормально во всех случаях
> оптимизировать.
> то есть до того что нужно СПЕРВА сделать выборку table1 а потом ее
> JOIN на все остальное додумается далеко не каждый планировщик. причем
> те планировщики которые умеют до такого додуматься, додумаются не
> всегда.

Силюсь понять, что имеется в виду.
Что значит "сперва сделать выборку table1, а потом ее JOIN"? Есть
какие-то планировщики, которые сначала сделают декартово произведение,
а потом только наложат условие? ДА ЛАДНО? Где это такая радость?
Нет - MySQL может неправильно выбрать driving table в существенно
более сложном, чем показано, запросе - но для таких случаев в нем есть
хинты. Или имеется в виду тот факт, что MySQL не умеет hash join, а
только nested loops? Ну да, не умеет. Но полное говно он не поэтому.


> то есть в постгре это все сразу улетает в секцию WITH. запросы
> начинают летать, а код становится недоступным для SQLLite/MySQL.
>
> в общем надо делать выбор БД на этапе ДО начала проектирования.
> удержать проект переносимым не получится.
>
> потому что даже в ORM используя скажем Pg, вы рано или поздно сядете
> за книжечку и построите скажем GIN индекс на нужную вам выборку.
> (мы вот пришли даже к тому что собственные варианты GIST пишем).
> и как только вы это сделаете проект перестанет быть переносимым.
>
> а сделаете вы это 100% в первые 0.5 года работы проекта под реальной
> нагрузкой
>
>> "ORM должен уметь триггеры и много чего еще, чтобы им пользовались не только
>> вы". У вас оно есть?.. А стоит-ли начинать?
>
> мы запилили целый проект на DBIx::Class. очень упорно убили год и
> где-то 500К строк кода.
> чтобы понять что ORM - зло.
> чистый SQL конечно не сахар, но лучшего ничего нет.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org