mySQL stored procedures and functions

[dzz]

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

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

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

Comments

[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 - нет. Они разные и решают разные задачи, поэтому переключение естественно.