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 плюс дополнительное поле со счетом. Вы хотите создать индекс включающий ВСЕ поля таблицы-посредника?

Urri ВладимирМПо первому пример понятно. Обсуждалась такая проблема. Я ее реализовал через триггер. Т.е. вместо 2 индексов для каждой таблицы я сделал по одному индексу для каждой таблицы и один общий триггер на все таблицы.
Интересно понять, как он работает, этот триггер (если Вы его описывали, то я пропустил).
Да также, как и индекс Candidat. Выполняет Select-SQL (или LOCATE FOR) на премет поиска записи с текущими начениями контролируемого выражения, исключая текущую запись.

Поскольку по искомому выражению есть индекс, то это обеспечивает выполнение следующих условий:

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

UrriЕсли таблица может иметь несколько одинаковых пар FK, значит, должен существовать еще по крайней мере один атрибут, с которым комбинация становится уникальной, и он(они) также должен быть добавлен в кандидатный ключ. Полностью одинаковых строк в таблице быть не должно - это нарушение одной из первых нормальных форм (никогда не мог запомнить, какой именно ;-)).
Ну, Вы, блин, даете! (с)

Повторяю еще раз:

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