Таблица может иметь только один первичный ключ, который может состоять из одного или нескольких полей. Когда несколько полей используются в качестве первичного ключа, их называют составным ключом.
Если таблица имеет первичный ключ, определенный на любом поле (ях), то вы не можете иметь две записи, имеющие одинаковое значение этого поля (ей).
Примечание – Вы могли бы использовать эти понятия при создании таблиц базы данных.
Создание первичного ключа
Вот синтаксис для определения атрибута ID в качестве первичного ключа в таблице Customers.
Для того, чтобы создать ограничение первичного ключа на столбце «ID», когда таблица CUSTOMERS уже существует, используйте следующий синтаксис SQL:
Для определения первичного ключа на нескольких столбцах, используйте синтаксис SQL приведенный ниже:
Чтобы создать ограничение первичного ключа на колонки «ID» и «NAME», когда таблица CUSTOMERS уже существует, используйте следующий синтаксис SQL.
Удаление первичного ключа
Вы можете очистить ограничения первичного ключа из таблицы с помощью синтаксиса, приведенного ниже.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
вот грубое упрощение интенсивной установки, с которой я работаю. table_1 и table_2 оба имеют первичные ключи суррогата автоматическ-инкремента как ИД. info — Это таблица, содержащая информацию об обоих table_1 и table_2 .
я пытаюсь решить, должен ли я сделать первичный ключ info композит идентификаторов из table_1 и table_2 . Если бы я сделал это, что из этого имеет наибольший смысл?
( в этом примере я объединение ID 11209 с ID 437)
INT(9) 11209437 (я могу себе представить, почему это плохо)
VARCHAR (10) 11209-437
DECIMAL (10,4) 11209.437
было бы хорошо использовать это в качестве первичного ключа на MySQL MYISAM DB?
8 ответов
Я бы использовал составной (многоколоночный) ключ.
таким образом, вы можете иметь t1id и t2ID в качестве внешних ключей, указывающих на их соответствующие таблицы.
Я бы не сделал первичный ключ таблицы "info" составным из двух значений из других таблиц.
другие могут сформулировать причины лучше, но кажется неправильным иметь столбец, который действительно состоит из двух частей информации. Что, если вы хотите сортировать по ID из второй таблицы по какой-то причине? Что делать, если вы хотите подсчитать количество раз, когда значение из любой таблицы присутствует?
Я бы всегда держал их как два разных столбца. Ты мог бы . используйте ключ primay с двумя столбцами в mysql . Первичный ключ(id_a, id_b). но я предпочитаю использовать уникальный индекс из двух столбцов и иметь поле первичного ключа с автоматическим приращением.
синтаксис CONSTRAINT constraint_name PRIMARY KEY(col1,col2,col3) например:
CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)
приведенный выше пример будет работать, если вы не написали его во время создания таблицы, например:
чтобы добавить это ограничение в существующую таблицу необходимо выполнить следующий синтаксис
составные первичные ключи, что вы хотите, где вы хотите создать связь "многие ко многим" с таблицей фактов. Например, у вас может быть пакет аренды для отдыха, который включает в себя ряд свойств. С другой стороны, недвижимость также может быть доступна как часть ряда пакетов аренды, либо самостоятельно, либо с другими объектами недвижимости. В этом случае устанавливается связь между свойством и арендным пакетом с таблицей фактов свойства / пакета. Этот связь между свойством и пакетом будет уникальной, вы только когда-либо присоединитесь, используя property_id с таблицей свойств и/или package_id с таблицей пакетов. Каждое отношение уникально, и ключ auto_increment является избыточным, поскольку он не будет отображаться в любой другой таблице. Следовательно, определение составного ключа является ответом.
помимо личных предпочтений дизайна, есть случаи, когда нужно использовать составные первичные ключи. Таблицы могут иметь два или более полей, которые предоставляют уникальную комбинацию, и не обязательно с помощью внешних ключей.
в качестве примера, каждый штат США имеет набор уникальных избирательных округов. Хотя многие государства могут индивидуально иметь CD-5, в любом из 50 государств никогда не будет более одного CD-5, и наоборот. Поэтому создание поля autonumber для Массачусетский CD-5 был бы излишним.
Если база данных управляет динамической веб-страницей, написание кода для запроса на комбинацию из двух полей может быть намного проще, чем извлечение/повторная отправка ключа с автоматическим номером.
поэтому, хотя я не отвечаю на первоначальный вопрос, я, конечно, ценю прямой ответ Адама.
Предположим, вы уже создали таблицу, теперь вы можете использовать этот запрос для создания составного первичного ключа
Перви́чный ключ (англ. primary key ) — в реляционной модели данных один из потенциальных ключей отношения, выбранный в качестве основного ключа (или ключа по умолчанию).
Если в отношении имеется единственный потенциальный ключ, он является и первичным ключом. Если потенциальных ключей несколько, один из них выбирается в качестве первичного, а другие называют «альтернативными».
С точки зрения теории все потенциальные ключи отношения эквивалентны, то есть обладают одинаковыми свойствами уникальности и минимальности. Однако в качестве первичного обычно выбирается тот из потенциальных ключей, который наиболее удобен для тех или иных практических целей, например, для создания внешних ключей в других отношениях либо для создания кластерного индекса. Поэтому в качестве первичного ключа, как правило, выбирают тот, который имеет наименьший размер (физического хранения) и/или включает наименьшее количество атрибутов.
Другой критерий выбора первичного ключа — сохранение уникальности со временем. Всегда существует вероятность того, что некоторый потенциальный ключ перестанет быть таковым в долговременной перспективе или при изменении требований к системе. Например, если номер студенческой группы включает последнюю цифру года поступления, то номера групп для идентификации групп уникальны только в течение 10 лет. Поэтому в качестве первичного ключа стараются выбирать такой потенциальный ключ, который с наибольшей вероятностью не утратит уникальность.
Исторически термин «первичный ключ» появился и стал использоваться существенно ранее термина «потенциальный ключ». Вследствие этого множество определений в реляционной теории были изначально сформулированы с упоминанием первичного (а не потенциального) ключа, например, определения нормальных форм. Также термин «первичный ключ» вошёл в формулировку 12 правил Кодда как основной способ адресации любого значения отношения (таблицы) наряду с именем отношения (таблицы) и именем атрибута (столбца).
Содержание
Классификация [ править | править код ]
Простые и составные ключи [ править | править код ]
Если первичный ключ состоит из единственного атрибута, его называют простым ключом.
Если первичный ключ состоит из двух и более атрибутов, его называют составным ключом. Так, номер паспорта и серия паспорта не могут быть первичными ключами по отдельности, так как могут оказаться одинаковыми у двух и более людей. Но не бывает двух личных документов одного типа с одинаковыми серией и номером. Поэтому в отношении, содержащем данные о людях, первичным ключом может быть подмножество атрибутов, состоящее из типа личного документа, его серии и номера.
Естественные и суррогатные ключи [ править | править код ]
Первичный ключ может состоять из информационных полей таблицы (то есть полей, содержащих полезную информацию об описываемых объектах). Такой первичный ключ называют естественным ключом. Теоретически, естественный ключ всегда можно сформировать, в этом случае мы получим т. н. интеллектуальный ключ.
