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

[metaclass]

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

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

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

Comments

[ennor.livejournal.com]

Ну че, update без where - классика. Думаю, каждый, кто правил базы ручками, проходил через это :)

А вообще да, выглядит сомнительно. MSSQL такое не пропустит, насколько я помню; более того, там вообще СУБД не указана...

[metaclass.livejournal.com]

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

[ennor.livejournal.com]

Ой, ну это вообще притча во языцех. Классический способ здорово подгадить жизнь не очень квалифицированной команде после твоего ухода:

set language english;
select min(ShipDate), max(ShipDate), count(*)
from AdventureWorks.Sales.SalesOrderHeader
where shipdate between '2004-07-05' and '2004-08-05';

----------------------- ----------------------- -----------
2004-07-05 00:00:00.000 2004-08-05 00:00:00.000 1121

set language russian;
select min(ShipDate), max(ShipDate), count(*)
from sales.SalesOrderHeader
where shipdate between '2004-07-05' and '2004-08-05';

----------------------- ----------------------- -----------
2004-05-07 00:00:00.000 2004-05-08 00:00:00.000 350

Мало кто полностью инициализирует все свойства соединения с БД сразу после его создания, обычно остается куча дефолтов из свойств логина или базы. Дефолтовый язык директорского логина поменять - и привет :)

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

[metaclass.livejournal.com]

Параметры да, это правильное решение.
Кстати, MSSQL умеет при парсинге запроса возвращать список и типы параметров?
А то я с ним иначе как через ADO.NET не работал, а там такое вообще не предусмотрено - список параметров заполнять исключительно ручками.

[ennor.livejournal.com]

Да, конечно. Даже из старого древнего ADO, когда используешь OLEDB-провайдер, он все сам находит и автоматом заполняет коллекцию параметров.
Правда, когда потом смотришь в профайлер, что же там реально бегает, то становится слегка нехорошо...