softwarerИмхо, слово "потенциальный" вполне подчеркивает, что речь идет не о существующем ключе.Ну да. Только после его введения именно этот потенциальный и становится настоящим ключом, а существующий до этого перестает быть таковым, и становится суперключом. Мне казалось, что это очевидно. Именно поэтому 2 решения, которые Вы предложили рассмотреть, являются принципиально разными, а не различаются всего лишь добавлением еще одного ограничения в первом из упомянутых.
softwarerИМХО описанная денормализация - основной плюс миграции идентифицирующих атрибутов, и это практически единственный вариант, когда составной ключ может оказаться оправданным.Опять не понимаю. Денормализация появляется только при миграции неидентифицирующих атрибутов, т.е., когда связь происходит не по одному из возможных ключей, а по суперключу. Если же связь происходит именно по ключу, пусть даже составному, то никакой денормализации нет. И оправданность с теоретической точки зрения только одна, это естественно, т.е., не требует появления каких-либо избыточных атрибутов типа суррогатных ключей, происходит в рамках стандартной нормализации и не вызывает никаких дополнительных аномалий.
Некоторые же из практических плюсов и минусов использования суррогатных ключей, как альтернативы составных, Вы упоминали ранее, и по ним у нас нет разногласий.

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

softwarerПризнаться, не припомню, чтобы в теории существовали такие понятия как "настоящий" и "ненастоящий" ключ.Такие понятия действительно отсутствуют, собственно, эти формулировки целиком на Вашей совести. Но условие неизбыточности потенциального ключа упоминается практически во всех изданиях по СУБД, считающихся классическими. По этой причине, по первому решению, комбинация (table#, table_column#) после добавления уникальности на table_column# выходит из категории потенциальных ключей и начинает относиться уже только к категории суперключей. Дейт даже делает специальную оговорку по поводу использования избыточного ключа в качестве внешнего, указывая, что такой подход явно ведет к денормализации, хотя это и так очевидно, чтобы быть поводом для оговорки. Максимальный суперключ, как крайний случай, включает в себя все атрибуты сущности на которой он построен, хотя не исключено, что он при этом останется потенциальным ключом. Впрочем, не вижу смысла мусолить одно и тоже, посему закрываю для себя эту нить обсуждения.

Кстати, был не совсем прав, по поводу определения суперключа. Есть немало разночтений этого термина вплоть до абсурдного - эквивалентности понятия "составной ключ" и "суперключ", но заслуживающими внимания, IMHO, можно считать понятия от апологетов или лиц, известных и авторитетных в определенных кругах. По их, в целом, общему мнению, под понятие суперключа подходит любой набор атрибутов, включающий в себя целиком хотя бы один потенциальный ключ. Из этого следует, что вырожденный случай, когда суперключ целиком равен потенциальному ключу также допустим. Впрочем, IMHO, это не принципиально в контексте обсуждаемой темы. В любом смысле, было полезно освежить свои знания.

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

ChA softwarer ChA softwarerИмхо, слово "потенциальный" вполне подчеркивает, что речь идет не о существующем ключе.Ну да. Только после его введения именно этот потенциальный и становится настоящим ключом, а существующий до этого перестает быть таковым,
:)) Признаться, не припомню, чтобы в теории существовали такие понятия как "настоящий" и "ненастоящий" ключ.Такие понятия действительно отсутствуют, собственно, эти формулировки целиком на Вашей совести.Прошу прощения, просмотрел, слово "настоящий" было действительно мною использовано, но, хотелось бы подчеркнуть, что не в качестве термина или понятия, а чтобы донести смысл, так как ряд используемых терминов ранее был признан неизвестным. Так что не вижу смысла в Вашей, несомненно остроумной, реплике.

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

ChA Сергей Васкецов...В контексте решения некоторых частных проблем требующих упрощенной идентификации записей посредством введения суррогатных ключей не вижу смысла...Прошу прощения, в результате правки смысл фразы сильно изменился. 37.5 ⁰ C не очень хороший помошник :(
Правильно так:
Если решение некоторых частных проблем требует упрощенной идентификации записей посредством введения суррогатных ключей, то не нахожу в этом сильной беды.

мод ChAОдним из таких объяснений является непонятный миф, что таблица обязательно должна иметь суррогатный ключ. Трудно сказать истоки его появления
Все очень просто - это необходимо вытекает из определения понятия Таблица.Процитируйте, пожалуйста, это определение и не забудьте указать источник. Что-то мне подсказывает, что ни Кодд, ни Дейт, ни многие другие апологеты с ним незнакомы.

модТаблица - это массив строк, т.е. каждая строка имеет индекс (какие еще источники .
ps поменьше апологетов слушайтеПросто какое-то нашествие практиков от сохи... :(

Нда, прямо на глазах от утверждения "нет ничего практичней хорошей теории" не остается ни камня на камне.
Сергей Васкецовчто любая строка в любой таблице в БД идентифицируется по полному имени таблицы и идентификатору строки. Внутри сервера БД такая идентификация есть всегда, но она в большинстве случаев недоступна для разработчика и может меняться со временем.Возможно не удивлю Вас, но такой идентификатор далеко не всегда представляет собой простое и однозначные число.
Сергей ВаскецовВ общем же случае безотносительно требования идентификации - это принципиальная ошибка в рассуждениях, в таблице вообще-то могут быть даже полностью идентичные записи с точки зрения select * from table.И Кодд может смело идти в сад, РМД здесь рядом не стояла. Действительно, если такое поведение позволяет себе то, что сейчас идет под названием РСУБД, то этого, оказывается, уже достаточно, чтобы считать теоретически обоснованным.