mySQL stored procedures and functions

[dzz]

Я очень хорошо понимаю, почему большая часть логики в mySQL-проектах реализована не в БД, на на application-side.
Потому что реализация хранимых процедур и функций в mySQL донельзя угробищна, например, в части bind-переменных. Особенно после Оракла :)

Даже самое элементарное, вроде SELECT COUNT(*) FROM XXX WHERE ID=:MY_VARIABLE в функции - полная задница, ибо prepared statements разрешены только в процедурах, а из них не вернуть значение.

А потом эти программеры выходят на "большие" СУБД.
Поубывыв бы.

Comments

[vitus_wagner]

Ага. А потом приходят писать хранимые процедуры программисты, которые ничего кроме джаваскрипта не знают и знать не хотят, а я им PL/V8 собирай.

[dzz.livejournal.com]

А может посылать их строем с "этой просьбой непотребной" © в сторону PL/pgSQL? :)

На mySQL я зол сегодня. Нечасто обращаюсь к этой БД, но тут в проекте понадобилось. Не смог сделать простой генератор уникальных случайных ID в виде хранимой процедуры.

Обходных способов дофига, но красиво "по-оракловому" не вышло.

[vitus_wagner]

Ну крупный заказчик, много денег может принести, как-то неудобно его посылать. И, возможно, он не один такой.
Причем мне тут пытались доказать, что PL/v8 работает с jsonb-полями в базе эффективнее чем PL/Python и PL/Perl хотя в 11-й версии для Pl/Python и PL/Perl есть нативное отображение jsonb в структуры соответствующего языка без промежуточной сериализации в строку, а для v8 (пока) нет.

[vitus_wagner]

А что касается нелюбви к mySQL, то я его вообще не люблю. Хуже я отношусь только к php.

[dzz.livejournal.com]

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

А что не так с PHP как языком, а не как паттерном применения "вставьте меня в HTML"?

[vitus_wagner]

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

Потом там оно как-то бессистемно спроектировано напихали всего подряд, а потом стали пытаться навести на это секьюрити. То есть оно insecure by design, хотя торчит в принципиально hostile среду.

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

[dzz.livejournal.com]

Все серьёзные PHP-фреймворки (да и несерьёзные тоже) первым делом обзаводятся средствами генерации стройного HTML-я в виде строк или файлов на выходе PHP-шных функций и методов :)

С безопасностью... Ну, да, это проблема начального дизайна, ещё со времён PHP/FI.

Хомячкам же редко надо что-то серьёзное на бэкенде, а вот возможность встроить в статическую HTML-страничку немножко серверного кода очень заманчива.

[dzz.livejournal.com]

Вообще, современное web-программирование - это жуткий конгломерат языков, на которых система работает параллельно: HTML+JS+CSS на фронте, PHP/что-то-там на бэке, *SQL со своими PL на уровне БД, и хорошо если сюда ещё пара уровней с другими языками не приползёт. И всё бы ничего, но сквозная отладка привращается в маленький такой ад.

[vitus_wagner]

Сквозная отладка - это везде ад. Даже в чистом C. Поэтому нужно иметь четко специфицированные интерфейсы между уровнями. которые отлаживать поотдельности.

[dzz.livejournal.com]

Так-то оно так, но постоянное переключение между синтаксисами в голове радости и безбажности не добавляет. Тебе же даже при правильно специфицированных интерфейсах нужно делать куски на SQL, PHP и JS, работающие согласованно, более-менее параллельно, если разработка идёт "в одно лицо", как у меня сейчас.

[vitus_wagner]

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

Хотя на мой взгляд, переключаться неудобно между близкими синтаксисами. Вот между perl и python - плохо.
А между make и shell или shell и c - нет. Они разные и решают разные задачи, поэтому переключение естественно.

[shkslj.livejournal.com]

Всем фоксбейса

[dzz.livejournal.com]

Издеваешься? ;)

[shkslj.livejournal.com]

А самым умным отгрузить dbase

[dzz.livejournal.com]

Ну, dbase был, как раз, простым и понятным, и без излишеств вроде хранимых процедур :)

Если уж чего отгружать, то адабаса какого-нибудь.

[shkslj.livejournal.com]

А я хз. Я примерно в тот сюмомент ебнул винтом об пол и сказал ни полшишечки моего зера в этом не будет... Ну соврал как водится.

[dzz.livejournal.com]

Я, как старый ораклоид и чуть менее старый постгресист, взираю на коммент с умилением :)

[shkslj.livejournal.com]

Поскольку пришлось сидеть и на стуле автоматизаторов и в рядовых пихотах бизнеса... Погромиздов надо бить. Хотя нет им это пофик их надо сажать в пихоты на полгодика тогда резко перестанут уставать и будут генерить полезный! код 200 знаков в минуту.

[dzz.livejournal.com]

Да щаз! :)
Будут генерить. Полезный. 200 знаков в минуту :)

Уж поверь опытному начальнику сборочного цеха, это не работает. По крайней мере, если у тебя нет роты хомячков-чистокодеров. Ибо быстронаписанный "полезный код" чреват тремя годами последующих багфиксов. Если людей гнать, они пишут как быстрее, а не как правильно подумать, а ошибки проектирования на раннем этапе обходятся ой как дорого.

[shkslj.livejournal.com]

Ну ок. 20 сим/мин. Чего еще ждать от...

[vitus_wagner]

который из - II, III или IV?

[shkslj.livejournal.com]

Я нипомню это было в прошлом веке:)

[vitus_wagner]

Да хоть в прошлом тысячелетии! Ну нельзя такие вещи не помнить, как нельзя, прожив 2000-й год, не помнить было в нем 29 февраля или нет.

[shkslj.livejournal.com]

Нннооо... Это и было в прошлом тысячелетии