softwarer iamherePK нужен всегда.
Докажете?Это аксиома - элементы множества должны быть различимы. Зачем в модель вводить сущность, экземпляры которой неразличимы ?
IMHO, то, что во многих современных СУБД существует возможность при создании таблиц не указывать PK - большая ошибка, и является постоянным источником ошибок для некоторых начинающих проектировщиков. Понятно, что СУБД на физическом уровне может отличить записи по физическому адресу, но РМД не может оперировать этим различием, так как не оперирует упомянутыми адресами в каком бы то ни было виде, тем более, что они не имеют ни малейшего смысла в контексте предметной области.
При общем отказе от обязательности нормального PK, определенного на множестве атрибутов, некоторые производители ввели искуственный системный идентификатор, который позволяет оперировать конкретными записями. К сожалению, это дает повод утверждать, что PK необязателен, с чем трудно согласиться, так как упомянутый идентификатор фактически играет роль PK.

softwarerВы смешали в одну кучу логику и физику.Боюсь, что с точностью до наоборот...
softwarer1. Все, что Вы сказали относительно "физического адреса записи", столь же относится к автоинкрементным полям и прочим вариантам суррогатного ключа. СУБД имеет одинаковые возможности манипулирования тем и другим, они равно бессмысленны с точки зрения предметной области - короче говоря, с точностью до технических деталей они полностью взаимозаменяемы.Ничего подобного, физический адрес может постоянно меняться, например, при расщеплении страниц данных, тогда как логический, на множестве атрибутов, пусть даже суррогатных, никогда. Относительно предметной области, сожалею, не указал, что под ней подразумевается ее модель с точки зрения проектировщика, а не с точки зрения ее пользователя. Мы ведь не на сайте бухгалтеров, для которого понятие PK отсутствует за ненадобностью, хотя может иметь смысл номер операции или проводки.
softwarer2. Вы совершенно зря полагаете, что в любой системе необходим идентификатор записи. Тривиальный пример задачи - какая-нибудь лента биржевых котировок с операциями типа

- Добавить (Кто, Когда, Сколько)
- Показать (Кто, ОтКогда, ДоКогда)
- ОчиститьСтарое (РанееЧем)

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

softwarerДопустим, у меня есть таблица из N полей, различимая по этим N полям.
...
1. Ввести поле суррогатного ключа. Это поле не будет использовано нигде и никогда в системе.
Значит, PK состоит из N полей и нет необходимости вводить дополнительный ключ.
softwarer
2...
...
3...
мне кажется, что из этих вариантов "большая ошибка" - один из лучших :))Физика - плата за несовершенство мира, модель предметной области не нуждается в понятии индексов, только в ограничениях, и как они реализованы к проектированию упомянутой модели совершенно не относиться. В любом случае, IMHO, физика не может являться доказательством ненужности PK и поводом для отказа от него, так как PK, в первую очередь, понятие логическое.

P.S. Кстати, те же суррогатные атрибуты в качестве ключей чаще всего дань той самой физике.

softwarer Ничего подобного, физический адрес может постоянно меняться, например, при расщеплении страниц данных, тогда как логический, на множестве атрибутов, пусть даже суррогатных, никогда.
А кто сказал, что он обязан меняться? Простите, это Вы у меня спрашиваете ? И кто - он ? Физический адрес ? Абсолютно не имею представления, от меня подобных утверждений не было, если только Вы не считаете слова "может" и "должен" синонимами. softwarer Здесь имеем расхождение в понимании PK. Для Вас это, скорее, физика, для меня - логика. О чем я и сказал изначально. Для меня PK - логика + физика. Вы говорите с позиции чистой логики, обобщая ее на физику.Никаких обобщений, могу только еще раз повторить, что PK - это логическое понятие, а то, что для поддержки данного вида ограничений производители СУБД, как правило, создают физический уникальный индекс, это дань физике. РМД ничего не знает об индексах, а вот об ограничении типа PK знает. softwarer Если существует однозначный и неизменный набор атрибутов, который позволяет отличить один кортеж от другого, то его уже можно смело считать PKНу, считать PK его на самом деле нельзя, но это отдельный вопрос, который предлагаю не обсуждать.Искренне заинтриговали. Хотелось бы увидеть Ваше определение PK, так как мое утверждение, в целом, не противоречит определению некоторых теоретиков РМД. Возможно, мне пора расширить кругозор. Надеюсь, оно не будет касаться того, что в таблице возможен только один PK, который является всего лишь одним из потенциальных ключей, и его, в принципе, не обязательно объявлять, если есть хотя бы один потенциальный, так как это очевидно любому, кто хоть раз заглядывал в соответствующие труды. Хотя, если PK рассматривать в смысле - логика+физика, то можно добавить пожелание минимальности из всех потенциальных ключей, отсутствия NULL-значений и, по возможности, неизменности на протяжении существования кортежа, но тогда продолжать дальнейшее обсуждение на тему действительно не имеет смысла, так как это выходит за рамки моего понимания PK, тем более, что подобное усиление не всегда возможно.
softwarerСформулирую утверждение, которое, полагаю, возможно строго доказать: введение суррогатного ключа не меняет функциональные возможности модели данных, не способно ввести ни одной осмысленной операции, невозможной при отсутствии такого ключа. Бессмысленные операции - может добавить, но кому они нужны?Не знаю, зачем из кустов все время выплывают суррогатные ключи, но классический пример - удаление дублей, которая решаема в отдельных СУБД, как упоминалось ранее, только благодаря введению суррогатного(!) системного идентификатора, играющего роль PK. В случае же отсутствия такового, если пытаться удержаться хотя бы в рамках ANSI-SQL, не говоря уж об РМД, операция перестает быть тривиальной. Следует отметить, что подобная задача не возникла бы в случае изначального следования проектировщиком постулатам РМД, и он сразу бы задумался над тем, что у него будет играть роль PK.
softwarerТеперь давайте посмотрим на изначальный вопрос.
...
Именно на эту фразу я отвечаю.ОК, будем считать, что неправильно понял Вашу фразу, точнее, вне контекста обсуждения. Хотя, IMHO, изначальный вопрос несколько невнятен.
Если связь между таблицами A и B вида 1:1, то введение дополнительного суррогатного(искуственного в терминах автора вопроса, если правильно его понял) ключа, действительно не имеет смысла, достаточно внешний ключ заодно объявить и как PK. Индекс, автоматически создаваемый при таком объявлении "движком" СУБД, будет полезен, как минимум, в таких операциях, как слияние таблиц, или обновление конкретной строки в таблице B. В случае же, когда одной записи из таблицы A соотвествует несколько записей из таблицы B, то PK опять же нужен, но объявлять ли его с помощью введения суррогатного ключа или поискать таковой на множестве существующих атрибутов таблицы B - это другой вопрос. Если PK не вводить, то возможность работы с уникальными записями из таблицы B исчезнет. С помощью операторов SQL станет невозможно ни обновить конкретную строку, ни удалить. Только если снести всю группу соответствующих записей из B, а взамен вставить группу-же тех, которые будут удовлетворять условию. Тоже, конечно, метод, но на любителя...
softwarer , в независимости от того, указал ли его проектировщик соответствующим видом ограничения или нет. Если такого набора не будет, то нарушается, как Вы выразились, постулат различимости.
Если такого набора нет в значащих данных, суррогатный ключ ничуть не улучшит ситуации.

Рассмотрите два набора данных:

ВасяПетяМашаСветаВася

и

1Вася2Петя3Маша4Света5Вася

Покажете ли Вы хоть одну операцию, в которой второй набор чем-то лучше первого при сохранении суррогатности ключа (то есть, грубо говоря, пользователь нигде и никогда не оперирует значением id)?Вы ввели этот пример, Вам и показывать :) Ранее упоминалось, попробуйте из первой таблицы удалить только одного Васю с помощью DELETE, но без использования rowid, или как оно там называется в Oracle, и разумеется, без групповых операций типа .
softwarer Кстати, те же суррогатные атрибуты в качестве ключей чаще всего дань той самой физике.Они дань тому, что программирование - инженерная дисциплина, а не гуманитарная. Наша цель - решать задачи, а не строить карточные домики.Веское заявление, но, увы, не уловил связи с моей фразой. Вы не согласны с моим утверждением ? Если так, то готов раскрыть его следующим образом:
Как правило, суррогатные ключи вводят именно с целью уменьшения физического размера ключей, которые затем мигрируют в подчиненные таблицы. Другой причиной появления суррогатных ключей, на практике более редкой, является проектировщик, который не может по тем или иным причинам выделить PK. Вы не согласны ?