Почему два первичных ключа в таблице не допускаются?

Question

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

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

Я пытался понять логику, но наткнулся на Правило 2 из 12 правил Кодда, которое гласит:

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

Должна ли комбинация имени таблицы, значения первичного ключа и столбца быть уникальной для одного базового значения или мы можем иметь несколько комбинаций, которые гарантируют доступ? Почему или почему нет?

Редактировать: Поскольку вопрос был определен как возможный дубликат, я объясню ниже, как он отличается Другой похожий вопрос был

Могу ли я иметь несколько первичных ключей в одной таблице?

Ответ - НЕТ .

У меня вопрос почему ? В чем причина?

Что Кодд намеревается сказать по правилу № 2?

Какие проблемы возникли бы, если бы было разрешено несколько отдельных первичных ключей?

Answer 1

«Первичный ключ» можно проследить до Теда Кодда , изобретателя реляционной модели , на которой свободно базируется SQL. Кодд ясно осознал, что когда отношение хранится в СУБД как переменная (relvar, r-таблица, таблица и т. Д.), Она может иметь несколько ключей-кандидатов, которые должны применяться. Первоначально он думал, что назначение одного или нескольких ключей в качестве «основных» может быть полезным. С тех пор (в конце 1960-х!) Мышление РМ пошло дальше, и идея «первичного» ключа больше не считается потенциально полезной. Аналогичное можно сказать и о нулях: Кодд предложил два типа нулей, то есть четырехзначную логику. Что я могу сказать? Этот человек был гением, но не непогрешимым!

К сожалению, многие из ранних идей РМ вошли в ранние реализации SQL и позже были закреплены в стандартах SQL. И из-за «оков совместимости» они никогда не будут удалены из стандартов SQL. Но эти вещи не были правильно реализованы в SQL. Например, Codd не указал, что relvar должен быть ограничен одним первичным ключом, но при реализации в SQL один для таблицы теперь является правилом. Зачем? Непонимание оригинальной статьи Кодда первыми разработчиками SQL? Умелое явное проектирование теоретиками отношений? Я полагаю, что вы замешаны в заговоре!

Различия между PK и эквивалентным NOT NULL UNIQUE ограничением незначительны и не очень полезны. Например, при указании PK в SQL вы должны указать ссылочную таблицу, но вы можете опустить столбцы ссылок. При указании столбцов они должны быть «равны набору имен столбцов в уникальных столбцах уникального ограничения ссылочной таблицы» (т. Е. Либо PK, либо любое ограничение NOT NULL UNIQUE). При исключении столбцов из определения предполагается использование PK таблицы, на которую есть ссылка. Если бы таблице было разрешено иметь более одного ПК, эта функция действительно не работала бы. Как я уже сказал, это не имеет большого значения, но может быть важно для некоторых пользователей.

Answer 2

С точки зрения нормализации

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

Строка может иметь любое количество ключей-кандидатов , каждый из которых может удовлетворять критерию первичного ключа. И я полагаю, вы могли бы назвать другие «вторичными» или «третичными ключами». Никто не делает этого, правда. Если требуется другое значение, например естественный ключ , обычно он устанавливается как атрибут, а не ключ.

При этом вы можете взять любые два столбца и назвать их составной ключ , а также объявить этот ключ первичным ключом. Таким образом, в отношениях первичного ключа действительно есть два столбца. Но это приводит к проблемам с производительностью.

С точки зрения производительности

Один ключ необходим и достаточен для достижения нормализованной схемы. Можно настроить более одного ключа, но они будут содержать избыточные данные - если вы знаете один, вы знаете другой, если вы знаете, кого спрашивать, - и нарушаете 2-ую нормальную форму. Это также означает, что каждый ряд будет занимать больше места, чем ему действительно нужно. Большая строка означает меньшее количество строк на странице, что означает более низкую производительность, особенно с учетом того, что первичный ключ используется в качестве ключа кластеризации и содержится в конечных страницах всех индексов в базе данных. Зачем тратить байты на то, что вы уже знаете?

Типичная практика

Сохраните любые дополнительные «ключи» как атрибуты в строке, где определена сущность. Например, вы можете сохранить номер социального страхования в качестве атрибута таблицы Employee, где EmployeeID является первичным (и, возможно, суррогатным) ключом. Всякий раз, когда вам это нужно, присоединяйтесь к таблице сотрудников. (И, между прочим, вы можете захотеть ужесточить разрешения на уровне столбцов SSN.) Не храните его в нескольких местах; в этом нет необходимости.

Answer 3

Первичный ключ имеет три свойства:

• Комбинация значений уникальна.
• Каждое значение в ключе NOT NULL.
• В таблице только один первичный ключ.

Таблица может содержать как комбинацию клавиш, так и комбинацию клавиш, которые удовлетворяют первым двум условиям. Вы спрашиваете, зачем нужны третьи определения.

Для определения реляционной логики удобно, чтобы у каждой таблицы был «именованный» метод доступа к определенной строке. Например, это дает руководство о том, как лучше определить отношения внешнего ключа (используйте первичный ключ). Это просто определение.

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

Answer 4

У вас может быть столько ограничений UNIQUE KEY, сколько позволяет ваша система баз данных, и теперь многие реляционные пуристы считают ошибкой поднять один этих ключей и помазать его как ПЕРВИЧНЫЙ.

Логически, ограничения уникального ключа и первичные ключи выполняют одни и те же цели - определяют подмножество столбцов, по которым строки могут быть однозначно идентифицированы. Они также должны иметь право в качестве целей для ограничений внешнего ключа.

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