[Moscow.pm] v2 просьба о ревью модуля DBIx::Struct
Ivan Petrov
i.petro.77.00 на gmail.com
Чт Янв 15 11:44:16 PST 2015
> Мои разглагольствования сводятся к двум мыслям:
> Голый SQL это плохо, если вы не умеете сахар на приложении.
мне кажется голый SQL это единственный способ строить нормальные
хайлоады.
как показывает практика ВСЕ кластерные решения (шардинг и проч) - вещи
ОЧЕНЬ интимные.
то есть например если у вас пользователи, то вам пойдет практически
любой вид шардинга, а если у вас таблицы с логами действий тех же
пользователей и вам надо выводить списки, то уже далеко не любой
подойдет.
далее, раз уж эту тему обсуждать далее.
я считаю что попытка делать приложение "переносимым между БД" ничего
удобного кроме тестов не дает.
ну только что тесты вы сможете делать на SQLLite, тогда как на боевом
у вас будет скажем Pg/MySQL.
но вопрос поднять тестовую Pg базу для проекта - несложный и я не вижу
в этом преимущества.
а далее начинается.
ну MySQL, как БД - полное говно, это понятно.
если говорить о Pg, то там например полно синтаксиса который можно
использовать для оптимизации скорости работы.
SELECT
*
FROM
table1
JOIN
table2
JOIN
table3
WHERE
table1.col = 10
до сих пор многие базы не научились нормально во всех случаях
оптимизировать.
то есть до того что нужно СПЕРВА сделать выборку table1 а потом ее
JOIN на все остальное додумается далеко не каждый планировщик. причем
те планировщики которые умеют до такого додуматься, додумаются не
всегда.
то есть в постгре это все сразу улетает в секцию WITH. запросы
начинают летать, а код становится недоступным для SQLLite/MySQL.
в общем надо делать выбор БД на этапе ДО начала проектирования.
удержать проект переносимым не получится.
потому что даже в ORM используя скажем Pg, вы рано или поздно сядете
за книжечку и построите скажем GIN индекс на нужную вам выборку.
(мы вот пришли даже к тому что собственные варианты GIST пишем).
и как только вы это сделаете проект перестанет быть переносимым.
а сделаете вы это 100% в первые 0.5 года работы проекта под реальной
нагрузкой
> "ORM должен уметь триггеры и много чего еще, чтобы им пользовались не только
> вы". У вас оно есть?.. А стоит-ли начинать?
мы запилили целый проект на DBIx::Class. очень упорно убили год и
где-то 500К строк кода.
чтобы понять что ORM - зло.
чистый SQL конечно не сахар, но лучшего ничего нет.
Подробная информация о списке рассылки Moscow-pm