Границы применимости решений

[metaclass]

Вот тут и тут идут практически идентичные срачи на тему "Зачем юзать (дорогую, энтерпрайзную, сложную) технологию А, если можно воспользоваться (простой, дешевой, десктопно-наколенной) технологией Б?".

А я, честно говоря, совсем уже потерял нить рассуждений, и не могу толком ответить на этот вопрос. Т.е. для меня вещи типа "бухгалтерию на dbf файлах в 2009 году не делают" и "mysql не является базой подходящей для систем со сложными расчетами и высокой нагрузкой" являются как бы самоочевидными, поэтому поиском аргументов на эту тему я себя никогда не утруждал.

Ну вот всегда, когда сталкивался с решениями на основе dbf (клариона, фокспро, клиппера, access, итд) - всегда очевидно, что разработчики блядь говно тупые уроды ебаные троечники по которым агрогородки плачут отстали от современных технологий, неважно по какой причине, соотвественно, они не способны принимать участие в современных разработках, у них нет для этого мыслительных категорий.
То же самое mysql, который в старых версиях, насколько я помню, вообще толком никакой логики на стороне сервера не содержал и транзакции умел только с одним типом хранилища. Для меня самоочевидно, что транзакции - это благо. И самоочевидно, зачем нужны вещи типа Software Transactional Memory и зачем нужны проверки целостности на стороне БД. Но большому количеству разработчиков это просто непонятно - я уже писал когда-то про попавшуюся под руки базу, в которой FK не было вообще.

С другой стороны - у меня в проекте Firebird молотит данные сотнями записей в секунду на обычном железе, с одновременными массовыми перерасчетами, и ничего. Хотя как бэ и СУБД тоже из разряда тех, на которые тупые линуксоиды наезжают в стиле "это же говно, потому что я так считаю".

И вот получается, что границы применимости решений (в данном случае СУБД) становятся совершенно непонятными. Очевидно, что при желании все недостатки отдельной СУБД можно обойти в программном коде. В экстремальных случаях это получится полное повторение функционала, уже существующего в другой СУБД, и это не всегда плохо - некоторые вещи настолько сделаны чрезмерно сложно и методом постепенного добавления фич, что переписывание с нуля их только улучшит.
Но вот где граница - "берем Postgresql, программиста и линуксоида на обслуживание" vs "покупаем Oracle, покупаем DBA, покупаем страшный софт за бешеные бабки и считаем что мы круты" - непонятно. Исключая, конечно, момент откатов за софт, тогда второй случай безальтернативен.

Comments

Re: нюню

[a-sure.livejournal.com]

Способ разбора запроса ребе считает не относящейся к делу мелочью? Особенно в плане того, как относиться к литералам?!?
Зря.

Чтобы не сваливаться в оффтоп - вот еще один компонент "границы": наличие или готовность купить лицензию на ОРАКЛ.

Re: нюню

[metaclass.livejournal.com]

А причем тут способ разбора запроса и cursor_sharing, если поведение очевидно бредовое?

Re: нюню

[a-sure.livejournal.com]

Ребе, такой момент:
1)я не имею привычки фантазировать. Есть прога (железка), и она устроена так, как устроена. Я предпочитаю знать, как:

"CURSOR_SHARING=SIMILAR causes statements that may differ in some literals, but are otherwise identical, to share a cursor by replacing the literals with system-generated bind variables, unless the literals affect either the meaning of the statement, or the degree to which the plan is optimized.

With CURSOR_SHARING=SIMILAR we look at replaced literals in some query predicates during optimization, to calculate the predicate selectivity. This is the normal effect of BIND PEEKING.
A side effect of this bind peeking is to potentially mark the bind as unsafe, so it is no longer shareable. This is done for range predicates (eg <, >=) or equality predicates in the presence of a histogram on the column. The purpose of this is to ensure we only share cursors when bind values lead to the same selectivity.

In 9i there was a problem (Bug 3668224) which meant that we could not peek bind variables in predicates if they were under operators, for example WHERE ENAME = UPPER(:b1).
The fix for this problem is in patchsets 9.2.0.6 and 10.2.0.3, but for 9i release it has to be explicitly enabled by setting event 38044.
There was also a follow-on problem (Bug 4359367) which meant that we were peeking excessively (in circumstances other than those appropriate for cursor_sharing=similar) but this is also fixed in 10.2.0.3."

Процесс разбора тоже документирован. Из касающихся вопроса - сначала идет проверка синтаксиса, потом, если сказано cursor_sharing=similar, литералы заменяются на псевдопеременные. Потом идет поиск уже разобранного запроса. И если находится такой же, то берется его план на исполнение. А сколько в тех запросах литералов, и как они раскиданы и что получается после bind_peeking - только по месту.

2) select case ... вкупе с упоминанием, что там тысячи таких, мне тоже нормальным не кажется. Но пока я не разобрался, откуда оно выросло - говном,хрупким и прочими эпитетами не разбрасываюсь.

Re: нюню

[metaclass.livejournal.com]

Не, если автозамена литералов на переменные для того, чтобы использовать скэшированный план приводит к нарушениям логики запросов - это таки показатель, что у разработчиков сервера не все в порядке с головой.

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

Re: нюню

[a-sure.livejournal.com]

1) запроса я не видел - только его начало
2) сколько похожих запросов, отличающихся только литералами, у них там еще?

Re: нюню

[plumqqz.livejournal.com]

Не, если автозамена литералов на переменные для того, чтобы использовать скэшированный план приводит к нарушениям логики запросов - это таки показатель, что у разработчиков сервера не все в порядке с головой.

Причем тут разработчики сервера? Есть два одинаковых запроса с разными параметрами - они имеют разные планы в зависимости от параметров, и выполняются, соответственно, по разному. (И разработчики сервера удолбались объяснять, что порядок строк без order by произвольный) Строки выборки, соответственно, могут идти в разном порядке. По всей видимости, приложение где-то неявно завязано на определенный порядок строк резалтсета - и в результате при его изменении получаем проблемы.

Тут наступили на аж на четыре грабли:
Грабля первая - не надо завязываться на определенный порядок строк
Грабля вторая - не трогай то, что влияет на не до конца понятные тебе вещи
Грабля третья - используйте параметры, а не литералы. Если используете литералы - четко понимайте, для чего это вы делаете.
Грабля четвертая - если использовать процедуры, то вышеперечисленные грабли обходятся автоматически: так просто на них не наступишь, это надо уметь делать.

Виноват во всем, разумеется, Оракл.

Re: нюню

[metaclass.livejournal.com]

А где там порядок строк, там же три поля в одной строке?

Как план запроса и замена литералов параметрами может вызвать такое, что: P1=True P2=True, но P1 and P2=False - мне непонятно, это вещи из разряда "в военное время синус может достигать 4"

Описанные грабли здесь к делу, по моему, не относятся.

Re: нюню

[plumqqz.livejournal.com]

Лехко:

select 1
from table where
(select val from table1 where rownum<2 and sum>N order by sum desc)

[Error: Irreparable invalid markup ('<m [...] </pre>') in entry. Owner must fix manually. Raw contents below.]

Лехко:
<pre>
select 1
from table where
(select val from table1 where rownum<2 and sum>N order by sum desc)<M and
P2=K
</pre>

Re: нюню

[gds.livejournal.com]

логику разбора и влияние данной опции на разбор и поиск плана я понимаю. На пару с дба честно накопали всю информацию, осмыслили, оба в ступоре. Более того, не представляете, как меня лично удивило влияние этой опции на выполнение запроса. Ещё может быть интересно, что по структуре этот запрос только один такой (не было других подобных; например, берущих из того же набора таблиц), и в нём нет bind variables вообще.
Пусть он заменяет литералы на bind variables, я не против (даже скорее за это), но зачем же неправильно вычислять результат применения "and" к двум предикатам? Один из ключевых моментов оптимизации -- неизменная семантика. А тут -- ёбаный стыд какой-то.

Re: нюню

[a-sure.livejournal.com]

1) он не заменяет литералы на Bind - я специально писал "псевдо". Мне счас негде уже (я дома) искать, но лежала где-то нота с металинка про поведение оптимизатора. Там скорее все литералы заменяются на одно и тоже для каждой позиции, после чего шарится в кеше уже разобранных запросов на предмет посимвольного совпадения.
2) второй источник засады - bind peeking, скорее всего именно эта штука вам всё и испортила. Это такой способ "припомнить", что было прошлый раз. И на основании этого строится план, в т.ч. и вычисление логики - "если первый предикат and уже ложен, второй вычислять не будем".


У каждого сложного продукта есть какие-то свои выверты, никуда ни денешься.