Всем привет.
Много лет как не использую FireBird, но новости подчитываю и мечтаю когда-нибудь перейти на него обратно с ненавситного MSSQL.

И тут вот на хабре попалась мне ссылка на презентацию

Инаписано там такое:

авторCommon SQL : BOOLEAN data type
Syntax
<data_type> ::= BOOLEAN
<boolean_literal> ::= TRUE | FALSE | UNKNOWN


Это что же получается, что я не смогу записать значение NULL в поле BOOLEAN, т.е. что-то типа




Это не прокатит что-ли?

Мне попробовать не на чем. Если работает, то почему список литералов не выглядит так:

<boolean_literal> ::= TRUE | FALSE | UNKNOWN | NULL

От вы интересный. И зачем оно мне надо ставить сервер и тулы и пробовать если я пишу что я с FireBird не работаю.
Я сюда пришёл обговорить это место с теоретической точки зрения чтобы все ещё раз это обдумали и сошлись во мнении хорошо это сделано или нет.

Ведь получается же как. Если считать что в списке литералов нет NULL, потому что кто-то думает что NULL - это не литерал, то тогда NULL - это не одно и то же что UNKNOWN.

Я вот читаю дальше там примеры идут с выражениями наподобие BOOLFIELD IS UNKNOWN. Типа как получается что здесь UNKNOWN используется заместо NULL. Ну так тогда возникакет вопрос: раз он такой же как NULL, то тогда он тоже должен не быть литералом и с каких дел он в списке допустимых значений предствлен.

А также и следующий вопрос возникает: раз NULL то же самое что UNKNOWN, тогда можно пи в других местах использовать UNKNOWN вместо NULL, с числами например.

Ну в общем я удочку закинул. Кто за это ответственен - он прочитает и ответит, если посчитает нужным.

Гаджимурадов Рустам, привет. Та зашёл тут, сколько лет прошло. Как меня кумарит этот MSSQL, если б ты знал, но никак не могу с него слезть, с реплотой всспоминаю о фаербёде и как Влад лично для нас сборки по почте с багофиксами присылал. Мыслимо ли это для MSSQL :-)

dimitr, и тебе привет. Ну я подозревал что вы так так это трактуете. Но согласись что в этом есть некоторая неоднозначность. Ты же пишешь что литерал - это функция, которая представляет значение NOT NULL. А UNKNOWN - представляет значение NULL и он литерал почему-то. Это называется "двойные стандарты".

Я понимаю что есть там стандарт и все дела, но этот UNKNOWN вносит смуту. Вы же, по сути, сделали его синонимом для NULL.

Вот что такое UNKNOWN? Это слово перводится как НЕ ИЗВЕСТНО. А если запихнуть в число NULL, то что это будет? Тоже ведь не известно? Тогда получается что этот UNKNOWN вполне подходит для применения вместо NULL повсеместно.

Вот у майкрософта по другому сделано. Они не парились особо и сделали такой тип данных как BIT, и всё. А EntityFramework его трактует как boolean. И нет вопросов и не надо никаких UNKNOWN

К тому же теперь пользователю надо соображать что чему равно UNKNOWN = NULL, UNKNOWN <> NULL, UNKNOWN IS NULL, UNKNOWN IS DISTINCT FROM NULL и все эти мутные штучки

Ещё скажу. Пишет пользователь так:




Потом делает SELECT BOOL_FIELD FROM MyTable

А что ты ему покажешь?

NULL
NULL

Так?

А у человека возникнет вопрос закономерный. Он скажет что он же литерал вставил, не NULL. Чё за дела, верните мой литерал. Все остальные литералы возвращает, а этот нет.

Гаджимурадов Рустам, та ну вот есть у нас кто на XP и там выше 2008 не получается. Тянули всех на 2008, но решил я на 2012 перходить. Делал инсталляцию. Щас же как хотят - чтоб всё в один клик ставилось. Начал встраивать в иснталлятор предустановку сервера, обычный весит под триста мегабайт, а с ManagementStudio гигабайт. Это ужас, не у всех же интернет нормальный. Потом триггеры ихние и курсоры - это ужас.

По поводу до буковки доколупался. Моё мнение такое что надо сначала всё продумывать, а потом делать. А то будет как помню с индексами по выражению. Сделать сделали, а потом оказалось что туда можно и подзапрос воткнуть и что угодно. И, с одной стороны, это лучше чем ничего, а с другой на лицо то, что теория плохо проработала и у определённой части людей это вызовет проблемы. Например у майкросовта есть понятие детерминированных функций и нет и контролируется что можно в выражениях использовать и что нет. И разница в том, что система больше защищена от неправильного использования. Врядли ты поспоришь что это хорошо.

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

Так мало того, я уверен что можно придумать выражение, которое завалит сервер, какой-нить CAST(UNKWNOWN AS ... b т.д. и т.п. написать, где оно не доделано, и всё.

авторПо идее

NULL
UNKNOWN

Я на 99.99999 уверен что это не так. Хотя где это написано? Опять же, лишние вопросы у людей.

Так надо бывает в базе пколупаться. А бывает надо просто приаттачить существующую или восстановить из бэкапа. Я же не могу в свой инсталлятор и конфигуратор напихать всё это - слишком круто будет.

К стати про UNKNOWN ещё придумал тему.

Раз это литералл, то человек подумает: ага, я могу использовать это в CHECK CONSTRAINT, и скорее всего у него что-то не срастётся...

Рустам, видишь, Денис проверил, я же говорил что NULL вернёт. А ты говоришь я доколупался до буквы.

Симонов Денис, а можешь проверить UNKNOWN IS NULL, UNKNOWN = NULL, UNKNOWN IS DISTICNT FROM NULL

Симонов Денис, да я и так прекрасно понимаю что должно быть. Это так, проверка что в сервере правильно сделано.

hvlad, привет :-)
Ну про bit - я в него постоянно нулы пишу. Лет 7 наверное. От тебя узнал что с этим проблемы могут быть.

авторPS Если тебя смущает UNKNOWN как литерал - просто забудь, что он есть. На практике ничего не изменится )
PPS А пришёл UNKNOWN из троичной логики (TRUE, FALSE, UNKNOWN)

Я то, слава богу, понимаю как он работает. Много чего в жизни я не понимаю, но это понимаю вроде :-)

Просто этот UNKNOWN будет постоянно сбивать с толку новичков, вот увидишь.

Я бы мог понять, наверное, если бы вы сделали и написали так: вводится новое ключевое слово UNKNOWN, которе является синонимом NULL.

как лично ты считаешь, выражение типа SELECT CAST(NULL AS INT) IS UNKNOWN логичное или нет? Я не вижу в нём ничего эдакого.

А такое выражение SELECT COALESCE(@Parameter AS UNKNOWN) = TRUE будет работать?

Вы же, объявляя какое-то слово литералом, наделяете его определёнными свойствами, а получается на практике что не совсем ото так, тот же пример с SELECT UNKNOWN возвращает NULL

А ещё вопрос что вернёт SELECT CAST(TRUE AS VARCHAR(10)), CAST(UNKNOWN AS VARCHAR(10))

Новички сойдут с ума ;-)

kdvДругое дело, зачем нужен литерал UNKNOWN, если он практически никогда не нужен

Вот! Он запутывает!!!

авторНу а я за 15 лет ни разу не нашёл причин его использовать.
За нуллы я уже сказал, что ошибся.


А на чём же ты к нему обращаешься? Видатьна чём-то раритетном. Я вот на EntityFramework с ним работаю и прекрасно он отображается на boolean. Что-то у тебя там совсем раритетное, наверное ;-)

Симонов Денис, написал неправильно

Надо так: SELECT COALESCE(@Parameter, UNKNOWN)

Глубокий смысл этого заключается в том, что тип параметра не известен, а COALESCE() помогает его определить по второму аргументу. Уже не помню по давности лет где это было нужно, но помню что было очень нужно.

Здесь, как раз, получается так, что UNKNOWN имеет смысл и тип данных для COALESCE(@Parameter, UNKNOWN) lолжен быть BOOLEAN, а для COALESCE(@Parameter, NULL) не известен (или вообще такое не должно компиллироваться ввиду абсурдности).

К стати, вот это вот FROM RDB$DATABASE я смотрю так и здравствует поныне, упрощённый синтаксис типа SELECT 1, 'abc' так и не разрешили :-(

Гаджимурадов Рустам, повторю, дело не в том, что оно вернёт в качестве данных, а в том, что оно вернёт в качестве типа столбца.

авторИ инсерты множественные обсуждались (не знаю,
добавили в тройку или нет). Ты тут на всё скопом
решил пожаловаться что ли? :)

Ну я же говорю что всё время хочу перейти. Хочется чтобы всё было прекрасно :-) ножественные инсёрты тоже вещь. Раз пользовался в жизни, зато как они не облегчили всё, ммммм :-)

Симонов Денис, это тоже вкусные плюшки. Но написать что-то типа

авторSELECT NULL AS Id, '(Not selected)' AS NAME
UNION ALL
SELECT Id, Name FROM MyTable

Это очень просто, прозрачно и удобно. Да, можно жить без этого.
Интересно, к стати, когда пишется что-то типа SELECT 1 FROM RDB$DATABASE, то происходят ли в движке какие-то лишние действия относительно RDB$DATABASE, которых можно было бы избежать?

А ты проверял или нет?

Если проверял, тогда ура, вот он, смысл и нужность этого UNKNOWN :-)