Как реализовать отношение 1..0 к 1..0.

Это ты сейчас с кем разговаривал?

Видимо плохой вопрос?

Есть таблицы A и B. Хочется следующее, допустим в B есть FK a_id (который может быть и NULL). Надо сделать так, что бы любые две записи в таблице B имели различные a_id(ну или NULL).
Т.е. по записи в A я мог достать не более одной записи в B. И по записи в B я мог достать не более одной записи в А.

Три таблицы: А (id_a), AB (id_a, id_b), B(id_b).
Два ограничения на внешние ключи: foreign key AB.id_a reference A.id_a, foreign key AB.id_b reference B.id_b.
Два триггера срабатывающих при вставке или обновлении, которые проверяют наличие существующих значений/

Тогда запросы на выборку записей из таблицы B, которые соответстуют записи в таблице А, которе равно Х  будут выглядеть так:

Аналогичный запрос для таблицы А будет выглядеть с точностью наоборот.

накинуть ограничение уникальности на b.a_id

ЧЕРЕЗ ТРИГГЕРЫ КОНТРОЛИРОВАТЬ ОГРАНИЧЕНИЕ ЦЕЛОСТНОСТИ - МОЖНО ТОЛЬКО В ОДНОПОЛЬЗОВАТЕЛЬСКОЙ СРЕДЕ!
Особенно на версионнике.
ты представь как это дожно работать, при конкурентых инсертах/делетах в режиме изоляции read commited.

За блокировочники не поручусь, там - свои ньюансы. Я их на вскидку не могу смоделировать, очень уж давно имел с ними дела.

Добавлено через 11 минут и 39 секунд

блин, проверил на MS SQL 2000, он nullы счиатает как заначения и проверяет по ним уникальность   

господа, прошу помочь мне сделать правильное заключение, какое из утверждений истинно:
1) Особенностью оракла является то, что ограничение уникальности по null не проверяется
1) Особенностью MS является то, что ограничение уникальности по null проверяется

блин, почему я не посмотрел название форума?  
от чегото был уверен, что мы в форуме "составление запросов", и платформа не указана.

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

А как тогда быть?


Не совсем понял.

MS:

оракля:


PG:


А как оно на FB, My?
Кто является исключением?

Это описано в документации на MS SQL.

Firebird:

Искуственно раскидывать блокировки,избавляясь от конкурентности сериализуя транзакции,  пытаясь избегать дедлоков.
В общем весьма не тривиальная и не всегда в полной мере реализуемая задача.

я в том нисколько не сомневаюсь.
мне было интересно насколько такая практика общепринята и чья реализации скорее исключение из правила  - ораклиная или ж MSSql'ная.

Zloxa, т.е. я так понимаю, что разработчики разных СУБД писали проверку по разному, одни так:

А другие вот так:

  ?

Это сообщение отредактировал(а) Gluttton - 27.9.2010, 12:14

По классике сравнение с null ВСЕГДА даёт false...

Добавлено через 4 минуты и 46 секунд




Видимо, надо выяснять, как к этому делу относится SQL92 =)

если быть чуть точнее - то unknown, либо же компромиссное "не истина".
потому как если мы сделаем чек констрейнт, который, как известно, срабатывает по false, он тоже не сработает на сравнении с null 
и, мне кажется, Gluttton, понимая это, очень даже изящно пошутил 

Я думаю тут ноги растут от того, что в ранних версиях sql сервера, Null трактовался совсем не по ансишному и троичная логика не была в нем реализована. Некросы это вроде как объясняли тем, что они прорелизились раньше стандарта. Рудименты этого решения, для обратной совместимости, тянутся и ныне.

Вот это да   .



Угу   .

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


Прочитал пару раз, но знакомых слов так и не нашел  , изложи пожалуйста мысль более доступно.

Я решил проблему для приложения(которое использует БД) с помощь Entity Framework. Сделав в бд отношение 1 ко многим (а_id int NULL в таблице B). А на стороне приложения с помощью Entity Framework'a ограничил многих как 0..1. 
Но понятно, что любое другое приложение может поломать логику работы с БД(да и руками можно за инсертить не валидные данные). И это вообще не решение.


+++

Я его не знаю. Я очень давно работал с MS SQL и плохо помню его особенности.

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


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

В результате имеем две единицы в табличке, наше ограничение не работает.
Блокировочник, в режиме read commited,  на шаге 4 должен бы встать на блокировке, потому как есть незакоммиченный инсерт этого значения. На версионнике блокировок по чтению не бывает, их придется колдовать. В окакле для этих целей есть select... for update, в FB, тоже должно быть чтото вроде. Начнешь колдовать блокировки - надо будет както разруливать ситуацию последовательного их захвата, чтобы избегать взаимоблокировок процессов(дедлоков). на данном примере сложно показать, так как тут ребуется захват лишь одного ресурса (таблицы) и вообще, для FB, и Oracle эта задача интереса не представляет.. я ж грю это вопрос для отдльной темы.


Это сообщение отредактировал(а) Zloxa - 27.9.2010, 23:33

Zloxa, 

Буду рад видеть  .