Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
Евгений Фадеев
Member [заблокирован]

Откуда: Russia, Moscow
Сообщений: 2374
CREATE TABLE TestPK(
ID	INTEGER	NOT NULL,
NullID	INTEGER	NULL,
	CONSTRAINT TestPK_PK
		PRIMARY KEY CLUSTERED (ID),
	CONSTRAINT TestPK_Pair_UQ
		UNIQUE (ID, NullID)
);

CREATE TABLE TestFK(
ID	INTEGER	NOT NULL,
NullID	INTEGER	NULL,
	CONSTRAINT TestFK_PK
		PRIMARY KEY CLUSTERED (ID),
	CONSTRAINT TestFK_TestPK_FK
		FOREIGN KEY (ID, NullID)
		REFERENCES TestPK(ID, NullID)
);
GO

INSERT INTO TestPK(ID) VALUES(1);
INSERT INTO TestPK(ID) VALUES(2);

INSERT INTO TestFK(ID) VALUES(1);
INSERT INTO TestFK(ID) VALUES(2);
-- А теперь самый сок!!!
INSERT INTO TestFK(ID) VALUES(3);
INSERT INTO TestFK(ID) VALUES(4);

SELECT * FROM TestPK
SELECT * FROM TestFK

DROP TABLE TestFK
DROP TABLE TestPK


На всякий случай
SELECT @@VERSION
------------------------------
Microsoft SQL Server 2012 - 11.0.2100.60 (X64) 
	Feb 10 2012 19:39:15 
	Copyright (c) Microsoft Corporation
	Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
28 апр 16, 17:00    [19118571]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Евгений Фадеев,

автор
Ограничение FOREIGN KEY может содержать значения NULL. Впрочем, если любой из столбцов сложного ограничения FOREIGN KEY содержит значения NULL, то при проверке будут пропущены все значения, составляющие ограничение FOREIGN KEY. Чтобы проверялись все значения сложного ограничения FOREIGN KEY, укажите для всех участвующих столбцов параметр NOT NULL.
28 апр 16, 17:10    [19118617]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
Евгений Фадеев
Member [заблокирован]

Откуда: Russia, Moscow
Сообщений: 2374
То есть, переводя на человеческий язык, "внешние ключи, содержащие NULL НЕ РАБОТАЮТ". При этом сервер не только позволяет их создавать (что уже странно), но даже не показывает, при этом, никаких предупреждений.
29 апр 16, 11:14    [19120795]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Евгений Фадеев
То есть, переводя на человеческий язык, "внешние ключи, содержащие NULL НЕ РАБОТАЮТ". При этом сервер не только позволяет их создавать (что уже странно), но даже не показывает, при этом, никаких предупреждений.

переводя на общедоступный: сервер абстрагируется от идиотизма которым его пичкают
29 апр 16, 11:21    [19120821]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
Akina
Member

Откуда: Зеленоград, Москва, Россия
Сообщений: 21242
А почему он должен показывать какие-то предупреждения? документация один раз предупредила - и достаточно, а кто не читал, тот ССЗБ.
Я уж не говорю о том, что каждый должен знать - конкатенация с Null всегда даёт Null...
29 апр 16, 11:22    [19120824]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
Евгений Фадеев
То есть, переводя на человеческий язык, "внешние ключи, содержащие NULL НЕ РАБОТАЮТ". При этом сервер не только позволяет их создавать (что уже странно), но даже не показывает, при этом, никаких предупреждений.
Всё правильно работает; все ключи, имеющие значения, проверяются; если в подчинённой таблице вставляются записи без значений FK ключей (т.е. когда хотя бы одно из полей содержит NULL), то не проверяется.
Если вам нужно проверять отдельно ссылку по ID, сделайте отдельный FK
29 апр 16, 12:07    [19121149]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
Евгений Фадеев
При этом сервер не только позволяет их создавать (что уже странно), но даже не показывает, при этом, никаких предупреждений.
В смысле, позволяет? Это же нормальная модель данных. Как это он "не будет позволять", а если мне нужны ограничения FK по двум полям, но когда оба заполнены?
Если же нужно сделать ограничение по одному из полей, когда второе не заполнено, тогда я просто создам ещё один FK, соответствующий этому ограничению.
29 апр 16, 12:10    [19121165]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
Евгений Фадеев
Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)
Это не глюк и не фича. Это основы SQL.
А как вам вот такой "забавный глюк"?
IF OBJECT_ID(N'tempdb..#T','U') IS NOT NULL DROP TABLE #T;

CREATE TABLE #T(X INT NULL CHECK(X IN(1,2,3)));
SELECT * FROM #T;

INSERT #T(X) VALUES(NULL);
SELECT * FROM #T;

IF OBJECT_ID(N'tempdb..#T','U') IS NOT NULL DROP TABLE #T;
29 апр 16, 12:52    [19121401]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
iap,

будем все забавные радости с NULL перечислять :)
29 апр 16, 12:57    [19121434]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
Евгений Фадеев
Member [заблокирован]

Откуда: Russia, Moscow
Сообщений: 2374
Akina
Я уж не говорю о том, что каждый должен знать - конкатенация с Null всегда даёт Null...

В конкатенация, в приведённом примере, пальчиком не ткнёте? Рекомендую как следует подумать перед ответом.
29 апр 16, 15:49    [19122638]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
Евгений Фадеев
Member [заблокирован]

Откуда: Russia, Moscow
Сообщений: 2374
alexeyvg
Всё правильно работает; все ключи, имеющие значения, проверяются; если в подчинённой таблице вставляются записи без значений FK ключей (т.е. когда хотя бы одно из полей содержит NULL), то не проверяется.

То есть это фича? "Внешний ключ работает, если определены все входящие в него поля. Если какие-то не определены - ключ не работает". Ну хорошо. Но, на мой взгляд, при создании внешнего ключа с nullable полями сервер должен бы предупреждение выдавать (не ленится же он это делать когда агрегаты считает).

alexeyvg
Если вам нужно проверять отдельно ссылку по ID, сделайте отдельный FK

Да я в курсе что и как мне нужно сделать, никаких проблем нет. Просто наткнулся на забавное (и, лично для меня, не очевидное) поведение сервера.
29 апр 16, 15:56    [19122685]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
Евгений Фадеев
Member [заблокирован]

Откуда: Russia, Moscow
Сообщений: 2374
iap
Это не глюк и не фича. Это основы SQL.

Эвона как! И в чём же именно они (эти основы) в данном случае состоят?
29 апр 16, 15:57    [19122696]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Евгений Фадеев
alexeyvg
Всё правильно работает; все ключи, имеющие значения, проверяются; если в подчинённой таблице вставляются записи без значений FK ключей (т.е. когда хотя бы одно из полей содержит NULL), то не проверяется.

То есть это фича? "Внешний ключ работает, если определены все входящие в него поля. Если какие-то не определены - ключ не работает". Ну хорошо. Но, на мой взгляд, при создании внешнего ключа с nullable полями сервер должен бы предупреждение выдавать (не ленится же он это делать когда агрегаты считает).

alexeyvg
Если вам нужно проверять отдельно ссылку по ID, сделайте отдельный FK

Да я в курсе что и как мне нужно сделать, никаких проблем нет. Просто наткнулся на забавное (и, лично для меня, не очевидное) поведение сервера.

потому что надо изучать материал, а не наугад тыкать и кричать баг/фича. Всё описано достаточно точно.
29 апр 16, 15:58    [19122698]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
Евгений Фадеев
Member [заблокирован]

Откуда: Russia, Moscow
Сообщений: 2374
TaPaK
переводя на общедоступный: сервер абстрагируется от идиотизма которым его пичкают
Возможно. Осталось объяснить его избирательность в данном вопросе.
29 апр 16, 15:58    [19122700]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Евгений Фадеев,

Складывается впечатление, что вы уже статью об этом "баге" в журналы разослали, а тут печаль... к чему ваши крики после первого комментария?
29 апр 16, 15:59    [19122703]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
Евгений Фадеев
Member [заблокирован]

Откуда: Russia, Moscow
Сообщений: 2374
TaPaK
потому что надо изучать материал, а не наугад тыкать и кричать баг/фича. Всё описано достаточно точно.

1. Где именно я кричал?
2. Какой именно материал нужно изучать?
29 апр 16, 16:00    [19122714]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Евгений Фадеев
TaPaK
потому что надо изучать материал, а не наугад тыкать и кричать баг/фича. Всё описано достаточно точно.

1. Где именно я кричал?
2. Какой именно материал нужно изучать?

https://technet.microsoft.com/ru-ru/library/ms175464(v=sql.105).aspx
29 апр 16, 16:01    [19122718]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
Евгений Фадеев
Member [заблокирован]

Откуда: Russia, Moscow
Сообщений: 2374
TaPaK
Складывается впечатление, что вы уже статью об этом "баге" в журналы разослали, а тут печаль... к чему ваши крики после первого комментария?


Рекомендую вам перестать принимать энергетики и другие нехорошие препараты. До добра это вас не доведёт.
29 апр 16, 16:02    [19122724]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
ок
29 апр 16, 16:08    [19122754]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
Евгений Фадеев
iap
Это не глюк и не фича. Это основы SQL.

Эвона как! И в чём же именно они (эти основы) в данном случае состоят?
Уточняющий вопрос: вы полагали, что foreign key (1,NULL) обязательно должен соответствовать primary key (1,NULL),
а (3,NULL) - (3,NULL)?

При этом подразумевалось, что NULL == NULL?
Надеюсь, вы в курсе, что согласно троичной логике это не так?

Поля FK могут содержать NULL, и это соответствует утверждению "этот FK ни на что не ссылается".
Ну правила такие. Вам же процитировали.
29 апр 16, 18:16    [19123305]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
iap
При этом подразумевалось, что NULL == NULL?
Надеюсь, вы в курсе, что согласно троичной логике это не так?
Однако, в свою очередь, есть ещё четыре "забавных глюка" в отношении сравнения двух NULLов -
это DISTINCT, UNION (без ALL), INTERSECT и EXCEPT.
В этих конструкциях NULLы сравниваются подобно любым другим значениям.
29 апр 16, 18:23    [19123322]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
Евгений Фадеев
Member [заблокирован]

Откуда: Russia, Moscow
Сообщений: 2374
iap
Уточняющий вопрос: вы полагали, что foreign key (1,NULL) обязательно должен соответствовать primary key (1,NULL),
а (3,NULL) - (3,NULL)?

На мой взгляд возможны два варианта:
1. Да, должны соответствовать (как это происходит в случае UNIQUE, например) и тогда третий INSERT в таблицу с внешним ключом должен давать ошибку
2. Нет, не должны. Но тогда первый же INSERT в таблицу с внешним ключом должен давать ошибку (так как кортежу <1, NULL> нет соответствия в мастер-таблице - потому что имеющийся там кортеж <1, NULL> не равен нашему <1, NULL>)

Любой из этих вариантов мне был бы понятен. А текущее поведение - нет.

iap
При этом подразумевалось, что NULL == NULL?
Надеюсь, вы в курсе, что согласно троичной логике это не так?

Я правда произвожу впечатление человека, который не читал Дейта, Кодда и т.д. и в предмете разбирается на уровне первокурсника-троечника? Если да, то это обманчивое впечатление.

iap
Поля FK могут содержать NULL, и это соответствует утверждению "этот FK ни на что не ссылается".
Ну правила такие. Вам же процитировали.
Ну, хорошо. Раз правила - значит правила. Просто для случая полностью NULLABLE кортежа внешнего ключа это понятно и очевидно. А вот для частичного - понятно не вполне. И вовсе не очевидно (см. выше про UNIQUE).
29 апр 16, 18:50    [19123381]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
iljy
Member

Откуда:
Сообщений: 8711
Евгений Фадеев,

http://citforum.ru/database/osbd/glava_18.shtml#_2_1_3_2
Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в отношении, на которое ведет ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать).


На практике в СУБД это требование обычно ослабляют и допускают частичную определенность полей внешнего ключа, который, тем не менее, считается неопределенным и не проверяется.
29 апр 16, 19:10    [19123436]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
Евгений Фадеев
тветствовать (как это происходит в случае UNIQUE, например) и тогда третий INSERT в таблицу с внешним ключом должен давать ошибку
2. Нет, не должны. Но тогда первый же INSERT в таблицу с внешним ключом должен давать ошибку (так как кортежу <1, NULL> нет соответствия в мастер-таблице - потому что имеющийся там кортеж <1, NULL> не равен нашему <1, NULL>)
А <NULL> тоже должен давать ошибку? Если есть просто NULL поле, с FK на другую таблицу?
А ведь правильно, многие теоретики вообще считают существование NULL значений недопустимым для чистой сферической реляционной алгебры. Но вот практики посчитали иначе.
Евгений Фадеев
Просто для случая полностью NULLABLE кортежа внешнего ключа это понятно и очевидно. А вот для частичного - понятно не вполне. И вовсе не очевидно (см. выше про UNIQUE).
Ну вот, именно поэтому этот момент специально отражён в документации :-)
29 апр 16, 19:25    [19123466]     Ответить | Цитировать Сообщить модератору
 Re: Забавный глюк (возможно это фича, но сильно в этом сомневаюсь)  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8805
Евгений Фадеев,
NULL - это не значение, это неизвестное состояние. Ключ не может быть неизвестным состоянием. Ключ всегда детерминирован.
2 май 16, 10:13    [19127969]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить