Запросы к БД, опечатки и строгая типизация

[metaclass]

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

И каждый раз удивляюсь тому, что разработчики СУБД ложат хер на теорию ради экономии на паре символов и псевдолаконичности и что SQL в разных серверах по разному реагирует на ошибки в типах данных.
А вот была бы строгая типизация - большая часть этих запросов ну нихрена бы тайпчекер не прошла.

Кстати, в этом плане полезен Firebird - там разработчики стараются жостко следовать стандартам, вплоть до того, что ломают обратную совместимость при переходе между версиями, если этого требует кошеризация.
Я вот жалею, что у меня почти нет опыта работы с Postgresql и Oracle - было бы очень интересно сравнить подходы на этот счет в разных серверах, а не только Firebird с MSSQL.

Comments

[demon-gloom.livejournal.com]

Cинтаксис, даже самый кошерный все не спасет. Нужно просто что бы программа перед выполнением запроса запроса проводила анализ кол-ва строк затрагиваемых изменением, и на основе обьема изменений требовала вводить капчу из того же квери. Самое главное при этом - подсветка слов в запросе разным цветом. И что бы символы -+,= отличались друг от друга цветом.

Типа если у меня в базе миллион строк, а квери затрагивает одну, то пускать без капчи. А если 500 тыщ, то раза два должно спросить.

[volodymir-k.livejournal.com]

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