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

[Ivan Petrov]

>> мне кажется голый SQL это единственный способ строить нормальные
>> хайлоады.
>> как показывает практика ВСЕ кластерные решения (шардинг и проч) - вещи
>> ОЧЕНЬ интимные.
>> 
>> то есть например если у вас пользователи, то вам пойдет практически
>> любой вид шардинга, а если у вас таблицы с логами действий тех же
>> пользователей и вам надо выводить списки, то уже далеко не любой
>> подойдет.

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

Вот допустим билинг у вас.
пользователь что-то сделал, а Вы с него денюжку считали.
все транзакции пишем в лог + баланс пользователя расчитываем.

Нужно уметь показывать выборки из этого лога
ибо пользователь захочет видеть отчет вида "списания с времени X до
времени Y"
соответственно такой лог где Вы предлагаете хранить?

далее если говорить о кластере то в контексте выборок списков шардинг
сюда ложится только с кучей оговорок

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

> Силюсь понять, что имеется в виду.
> Что значит "сперва сделать выборку table1, а потом ее JOIN"? Есть
> какие-то планировщики, которые сначала сделают декартово произведение,
> а потом только наложат условие? ДА ЛАДНО? Где это такая радость?

в MySQL и Pg. сюрприз?
иногда очень много усилий надо приложить чтобы ЗАСТАВИТЬ Pg делать
выборку ДО JOIN.

вторая проблема, толкающая в свой синтаксис - заставить использовать
именно нужный индекс.

это пожалуй единственная хорошая черта MySQL - то что можно сказать в
явной форме какой индекс использовать для запроса.
в Pg если у Вас частичный индекс размером 100Кб построенный специально
для данного запроса, то он все равно может решить использовать
8Гиговый индекс по каким-то своим внутренним соображениям.
и единственный способ убедить его как надо правильно действовать -
WITH.