mir YulkaВвиду того, что проблема чуть ли не повсеместная (длиннющих составной естественный ключ с потенциальной изменчивостью, сам из внешних, необходимость миграции неключевых дальше и т.д.), опять же давно бы решили на уровне СУБД.Да, в общем, и нет никакой проблемы. Тем более такой, чтобы решать на уровне СУБД. А что такое "миграции неключевых"?

Мне показалось, что Вы ниже согласились со мной, что суррогатные ключи нужно прошить в подкорку. Но они не прошиты, и вводится и суррогатный PK и UNIQUE INDEX на потенциальные ключи. В то время как это (если исключить изменчивость естественных) - по сути одно и то же, и может быть использовано как одно и то же. Но ввиду того, что те, что я объявила UNIQUE INDEX, не являются PK, я не могу их точно также использовать дальше (в вычислениях, в зависимых таблицах), а должна вручную их контролировать там. Это я условно и назвала транзитным ключом, наследованием и синтезом разные модификации еще называют. Я не говорю, что они всем нужны, но мне там нужны, я вычислениями занимаюсь, а не учетные задачи пользователя обслуживаю.

автор YulkaВопрос, хоть проверка уникальности PK и UNIQUE INDEX оптимизирована? Или тоже дважды проверяется?Все нормальные РСУБД для PK автоматически создают UNIQUE INDEX, с помощью которого и проверяется уникальность. "Руками" делать ничего не надо.
Простите, я подумала, что понятно из контенста предыдущих обсуждений и обсуждаемой ситуации: есть суррогатный PK и ДРУГИЕ поля, являющиеся UNIQUE INDEX для данной таблицы. Проверять уникальность PK и их ОТДЕЛЬНО это бред, с моей т.з. Вот я и спрашивала, оптимизирована ли такая ситуация в современных СУБД.

автор YulkaИ студентов с множествами учить работать, а не с ключами.Это что же за такое противопоставление: множества VS. ключи? Что бы это значило?

Это противопоставление содержательной разработки (теоретико-множественных органичений предметной области) и технической реализации, которая (в ключах, в моделях данных, в СУБД и т.д.) может быть разная.

авторСУБД работает с множествами - адресуемыми элементами данных. Адресное пространство - множество в силу своего устройства.
Все проблемы - во взаимодействии с внешним миром. Например, мы знаем, что люди образуют множество, но не имеем возможности эффективно его представить. Более того если однажды установлена связь человека и записи БД, то нет 100% надежного способа эту связь сохранить.
Извините, но я не считаю, что люди образуют множество. Это разные миры: множество это теоретический искусственный объект, используемый для контроля и оперирования стабильным общим, а люди и другие объекты они бесконечны (в смысле непознаваемы до конца, никакого определения человека пока не придумано), и мы им приписываем те признаки (из бесконечного многообразия признаков), который нам нужны для оперирования ими. Я считаю, что люди - это еще очень благодарные объекты для приписывания признаков - они хотя бы рождаются и умирают, и во времени пока не путешествуют. Соответственно для таких объектов, если бы мы жили в матрице, нужна система регистрации рождения и смерти, она по крайней мере гарантирует идетифицируемость, а дальше просто гарантировать, чтобы они свой идентификатор таскали всегда с собой и не могли от него избавиться (тут прав Сахават). Других путей полной идетификации людей и аналогичных объектов я, например, не вижу.

авторYulka
Опять же, таблицы вообще без PK – это аномалия, это НЕ МНОЖЕСТВО

1. Таблица вообще не множество
2. Пример: поток событий - могут отличаються только порядковым номером, т.е. номером строки таблицы.
Если Вам множества не нужны, то не используйте их, всему свое место. А поток событий, отличающихся только порядковым номером (если он не значимый, конечно, этот порядок, потому как порядок может быть только на множестве, например, это порядок во времени возникновения, то уже может понадобиться в качестве множества), - это, действительно, не множество. Я бы для таких объектов использовала другие механизмы.

mcureenab Yulka автор YulkaВопрос, хоть проверка уникальности PK и UNIQUE INDEX оптимизирована? Или тоже дважды проверяется?Все нормальные РСУБД для PK автоматически создают UNIQUE INDEX, с помощью которого и проверяется уникальность. "Руками" делать ничего не надо.
Простите, я подумала, что понятно из контенста предыдущих обсуждений и обсуждаемой ситуации: есть суррогатный PK и ДРУГИЕ поля, являющиеся UNIQUE INDEX для данной таблицы. Проверять уникальность PK и их ОТДЕЛЬНО это бред, с моей т.з. Вот я и спрашивала, оптимизирована ли такая ситуация в современных СУБД.

А кто гарантирует уникальность? Кто мешает назначить записи суррогатный ключ, который уже есть в таблице? Кто мешает назначить записи уникальный ключ, который уже есть в таблице? Исключить двойную проверку можно только при наличии взаимнооднозначного преобразования суррогатного первичного ключа в уникальный и наоборот и это преобразование должно находиться за пределами самой таблицы.

Нет, тут Вы совершенно правы, но я не предлагала не проверять, я предлагала проверять одновременно, а не каждый по отдельности. Может, неточно выразилась :-(

mcureenab Я так понял раздражает то, что подменив живой внешний ключ на суррогатный мы теряем возможность определить декларативное ограничение целостности уровня записи в котором участвуют колонки живого ключа (теперь они находятся в справочной таблице). Это не большая проблема, в общем случае она решается на уровне триггеров БД, а создание триггеров, которые проверяют целостность данных как правило легко автоматизируется.

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

mcureenab Yulka mcureenabА кто гарантирует уникальность? Кто мешает назначить записи суррогатный ключ, который уже есть в таблице? Кто мешает назначить записи уникальный ключ, который уже есть в таблице? Исключить двойную проверку можно только при наличии взаимнооднозначного преобразования суррогатного первичного ключа в уникальный и наоборот и это преобразование должно находиться за пределами самой таблицы.

Нет, тут Вы совершенно правы, но я не предлагала не проверять, я предлагала проверять одновременно, а не каждый по отдельности. Может, неточно выразилась :-(

Одновременно или поотдельности, нет разницы. Если объявлены ограничения уникальности, то современные СУБД для каждого такого ограничения строят индекс, а индексы по любому надо актуализировать когда индексированная запись изменяется. Поэтому обнаружение дубля становится маленькой проверкой в большом потоке работы. С другой стороны искать дубли без индекса будет ещё дольше.
И вообще, что значит "одновременно"? Я так понял, что если один ключ уникален, то второй можно не проверять. Или я ошибаюсь?

Действительно, что-то не о том. Речь об оптимизации проверки, и делают ли ее СУБД. Отвлечемся от РК, пусть просто в таблице есть две группы уникальных индексов с живой изменчивостью. Чтобы проверить уникальность одного, мне надо перелопатить все записи (про внешние молчу). Я думаю, что одноврменно при этом проверяются и другие уникальные индексы (без дополнительного перелопачивая). Или это не так и проверка по следующему идет заново? Тут обсуждать нечего, тут ответ да-нет предполагается :-)