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

[metaclass]

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

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

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

Comments

[guamoka.livejournal.com]

Недавно довелось подменять под Hibernate Oracle на hsqldb, ибо индусы хотели, чтобы было энтерпрайзно, но оно там нафиг не упало. Обнаружилась любопытная (общеизвестная) вещь, что Oracle хранить пустые строки как null (а на проверку на нулл была завязана ветвистая логика) :) Вот тебе и типизация.

[metaclass.livejournal.com]

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

[volodymir-k.livejournal.com]

Никаких заморочек нет. Оракл принял свое решение в 1985, а потребовалось стандартизировать в 1992 году, и очевидно, что им важнее существующие покупатели, чем стандарт. У Микрософта и во многих других есть режим ANSI strict и т.д. Вроде у Оракла тоже должно быть.

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