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, 

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