metaclass: (Default)
[personal profile] metaclass
Неоднократно читал истории, типа этой, когда из-за мелкой опечатки убивалась целая таблица данных.

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

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

Date: 2010-02-01 07:44 pm (UTC)
From: [identity profile] metaclass.livejournal.com
Вот таких вот тонких заморочек в разных серверах просто горы, что и удивляет. Скорее всего, когда-то давно забили на нормальное проектирование, а потом просто решили не ломать совместимость.

Date: 2010-02-02 12:23 am (UTC)
From: [identity profile] volodymir-k.livejournal.com
Никаких заморочек нет. Оракл принял свое решение в 1985, а потребовалось стандартизировать в 1992 году, и очевидно, что им важнее существующие покупатели, чем стандарт. У Микрософта и во многих других есть режим ANSI strict и т.д. Вроде у Оракла тоже должно быть.

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

Profile

metaclass: (Default)
metaclass

April 2017

S M T W T F S
      1
2345678
9101112 131415
16171819202122
23242526272829
30      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 22nd, 2025 02:58 pm
Powered by Dreamwidth Studios