1. Уникальный идентификатор записи - это то, что пользователь ни в коем случае не должен редактировать руками. Даже видеть его не должен! Это все идет на "откуп" внутренних функций генерации. В этом случае использование кодов ранее удаленных записей - в принципе недопустимо.

2. Пользователь может видеть (и редактировать) некое краткое обозначение (Nick Name). А в этом случае никто не мешает ввести повторяющееся значение. Контроль уникальности среди НЕ удаленных записей можно повесить на триггер.

help123Объясню для чего мне все это нужно:
большую важность для меня имеет в базе данных связь один-ко-многим. В этом случае я могу настроить эту связь так, что при изменении кода продавца в главной таблице (все бывает - в бухгалтерии девченки код неправильно присвоили, а в конце месяца опомнились ) - он автоматически изменится во второстепенной таблице во всех записях. А чтобы эту связь создать - необходимо глючевое поле в главной таблице с уникальными даными. Вот поэтому их пользователь и вводит вручную.
- Передаем сигналы точного времени "пи-пи-пи"
- Для тех, кто не расслышал, передаем их еще раз "пи-пи-пи"

Повторяю еще раз. Ну не должны пользователи сами вводить значения ключевых полей (суррогатного ключа). Просто не должны. Этим вы избежите огромного количества проблем в будущем.

Например, описанная проблема просто не возникнет. Какая разница, что там девченки ввели в качестве NickName. На организацию связи это вообще никаким боком не влияет. Ведь связь идет по неким "внутренним" кодам, которые пользоваитли вообще не видят

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

help123 Igor KorolyovЭто не поможет... А почему не поможет? Можно ведь и не затирать в прямом смысле - а просто заменить на специально сгенерированную уникальную строку.
Слушай, а самому чуть-чуть подумать?

Твоя проблема возникла от того, что записи физически не удаляются, а лишь помечаются как удаленные. Теперь представь, что ты перед удалением очищаешь это поле. Один раз - замечательно. А второй - получишь сообщение об ошибке, что такое поле уже есть. То самое - очищенное, что было удалено ранее. Пустое значение - это тоже значение! А значение NULL для Primary-индексов - недопустимо!

Так что, по сути, у тебя только 2 принципиальных решения:

либо не давать пользователям править ключевое поле

либо в случае возникновения подобного конфликта попросить выполнить очистку базы данных от записей ранее помеченных как удаленные

Большая просьба. Прежде чем начать говорить, что это невозможно, да это требует эксклюзивного доступа и т.д. и т.п. Ответьте себе на несколько вопросовю


Насколько часто возникает подобная ситуация?

Стоит ли писать очень сложный код для решения этой проблемы, если ситуация крайне редкая?

UrriКстати, это только в совсем нормализированных таблицах комбинация полей в записи зависит от первичного ключа и только от него. А на практике бывают еще и кандидатные индексы. Я, например, сторонник такого подхода:
PK - суррогатный.
Кандидатный ключ - как правило, один на таблицу, но даже если и больше - строится с условием FOR NOT DELETED().
Прошу покритиковать ;-)
Почитай здесь

Раздел "Ключевые поля"
http://www.foxclub.ru/kb/index.php?sid=24056&aktion=artikel&rubrik=001&id=6&lang=ru

UrriВладимир, у тебя в статье как раз вопрос о кандидатных ключах не освещен (я не увидел). А ведь, по сути дела, использование кандидатных ключей - это отличный (а порой и необходимый) способ добавить целостности в БД.
У Вас какая-то путанная терминология получается.

Цель ключевого поля (PK - Primary Key) - однозначная идентификация записи. Все! При этом в пределах ВСЕЙ таблицы значение PK для каждой записи уникально.

Цель внешнего ключа (FK - Foreign Key) - это хранение значения PK. Все! При этом в пределах ВСЕЙ таблицы значение FK - НЕ уникально.

Что Вы подразумеваете под "кандитаным ключем" - непонятно.

UrriВот например, твой пример с реализацией отношения "многие ко многим" через третью таблицу. Если в ней используем суррогатный PK, то связи с первой и второй таблицами получаются неидентифицирующими, и тогда - по обстоятельствам - надо назначать кандидатным ключом или пару ID первых двух таблиц (если конкретная запись первой должна быть связана с конкретной записью второй не более одного раза), либо эту пару и дополнительный(е) атрибут(ы).
Опять у Вас какая-то "каша" получается. Разве я писал, что надо отказаться от FK при такой связи? Я там написал, что кроме 2 существующих FK надо добавить еще одно поле PK. Я настаиваю на том, что в такой ситуации использование пары FK, как заменитель PK - заведомо порочная практика!

Т.е. в подобной ситуации связь организуется по классической схеме от PK главной таблицы к FK таблицы-посредника и от второго FK таблицы-посредника к PK подчиненной таблицы.

А вот PK таблицы-посредника выполняет совсем другую функцию. К организации связи он вообще не имеет никакого отношения. Его цель - однозначная идентификация записи. ВСЕ!

UrriА критику я хотел бы услышать по всем направлениям, в том числе, нет ли у кого адекватного варианта получше, в плане производительности, например, простоты реализации и т.п. Есть ли ситуации, которые этот подход плохо отрабатывает. Ну и т.д. ;-)
Конечно есть! У меня, например

Индекс с FOR-условием не участвует в оптимизации. Т.е. скорость выполнения запросов падает. Для ускорения нужен еще один простой индекс, но уже без FOR-условия.

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

Причем я написал "универсальный" (в пределах моей задачи) триггер. Т.е. один общий код для любых таблиц.

PaulWist ВладимирМ
ВладимирМ Цель внешнего ключа (FK - Foreign Key) - это хранение значения PK. Все!
Вот здесь, ещё бы добавил - и обеспечение ссылочной целостности.
Нет. Обеспечение ссылочной целостности - это отдельный процесс ! FK - это элемент этого процесса. Но он никак, никоим образом, не может обеспечить ссылочную целостность.

Ведь в организации ссылочной целостности участвует и PK, но тебе и в голову не приходит добавлять, что цель PK - это обеспечение ссылочной целостности!

Вообще-то, чем меньше использовать разной "терминологии" (пусть и официально признанной), а просто рассказывать что и для чего делаешь, то, как правило, и сам понимаешь в чем ошибся и тебя быстрее понимают и поправляют.

PaulWist
В принципе, есть к чему придраться Однако так можно продолжать до бесконечности. Мы друг друга поняли, а уточнение формулировок - это уже детали...

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

По первому пример понятно. Обсуждалась такая проблема. Я ее реализовал через триггер. Т.е. вместо 2 индексов для каждой таблицы я сделал по одному индексу для каждой таблицы и один общий триггер на все таблицы.

По второму примеру опять ничего не понял. Какое отношение имеет PK в таблице-посреднике к организации связи? Он там вводится совсем не для этого!

Вы делаете ничем не обоснованное допущение, что пара FK должны быть уникальны в пределах таблицы-посредника. Почему собственно?

По ссылке я привел пример: один клиент имеет несколько счетов в одном и том же банке. Т.е. в таблице-посреднике несколько одинаковых пар FK плюс дополнительное поле со счетом. Вы хотите создать индекс включающий ВСЕ поля таблицы-посредника?