Может ли таблица базы данных содержать более одного первичного ключа?

Question

Может ли таблица базы данных содержать более одного первичного ключа?

Да, я говорю о РСУБД.

Answer 1

Первичный ключ таблицы реляционной однозначно идентифицирует каждую запись в таблице. Итак, чтобы сохранить уникальность каждой записи, у вас не может быть более одного первичного ключа для таблицы. Это может быть либо нормальный атрибут, который гарантированно будет уникальным (например, номер социального обеспечения в таблице с не более чем одной записью на человека), либо он может быть сгенерирован СУБД (например, глобально уникальный идентификатор или GUID , в Microsoft SQL Server). Первичные ключи могут состоять из одного атрибута или нескольких атрибутов в комбинации.

Answer 2

таблица может иметь:

• нет первичных ключей;
• Один первичный ключ, состоящий из одной колонки; или
• Один составной первичный ключ, состоящий из двух или более столбцов.

Помимо этого, у вас может быть любое количество уникальных индексов, которые будут делать в основном одно и то же.

Answer 3

Вот почему это называется первичным ключом, потому что, ну, ОСНОВНОЙ

Answer 4

Да, вы можете иметь составные первичные ключи, то есть иметь два поля в качестве первичного ключа.

Answer 5

Прежде всего, вам необходимо понять историю методологии проектирования сущностей, а также понять слово «реляционная» в системах управления реляционными базами данных (РСУБД).

Чтобы определить границы сущности и отношений, которые должны быть сформированы, должен быть уникальный дескриптор или уникальная комбинация ручек для идентификации каждого отдельного экземпляра объекта, а затем для формирования отношений между ними.

Вам также необходимо понять значение/корень слова «идентифицировать», которое равно нулю в «идентичности» каждого экземпляра объекта. «идентичность» - это математический термин, означающий «один» или сингулярность.

Согласно принципам реляционной методологии, каждый объект должен иметь только одно и только одно средство для его идентификации. Следовательно, СУБД «R» пытается облегчить моделирование отношений сущностей. Обратите внимание на различия между «Entity/Class» и «Entity/Class instance».

Однако РСУБД широко используются и в основном людьми, которые не очень заинтересованы в точном изображении принципов проектирования E-R. Так что часто, у нас есть более одного возможного определения сущности внутри таблицы, которое я называю сглаживанием сущностей. Противоположность идентичности сглаживания, где два или более экземпляров сущностей-набор скрывающих под тот же ключом, сущность ступенчатость подобна таблице

EmpProj([empId], empName, empAddr, projId, projLoc) 

на самом деле имеет две сущность наборы псевдонимов под одной и ту же таблицей:

Emp([empId], empName, empAddr) 
Proj([projId], projLoc, empId) 

То есть при нормализации - для отделения этих объектов. Попытайтесь, чтобы мы могли сделать достойную нормализацию дизайна, у компьютерных ученых может быть не так хорошо просматривается информация, как статистик.Ученый-компьютерщик (который в этом обсуждении включает всех, у кого есть достойные знания о дизайне ER) пытается сделать все возможное для создания схемы, которая четко определяет сущности и их отношения.

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

Это то, где альтернативные уникальные ключи хороши для - идентификации экземпляров объектов из-за основных компонентов, существующих как сущностные объекты в базе данных.

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

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

В заключение, ограничение, предоставленное производителем СУБД «R» в разрешении всего одного первичного ключа на таблицу, является их предлогом в том, что они знают, как ведет себя информация и полагают, что основные компоненты информации, связанные с населением, не являются мутировать с течением времени.

Если у вас есть более одного уникальных ключей возможно в таблице означает, либо один или несколько возможностей

1. Как и я, вы ленивы, чтобы разделяющие их, так как они, кажется, работы достаточно хорошо
Для выполнения сакэ
2. », смешивая объектов в ту же таблицу делает приложения работать невероятно быстрее
3. Как и статистикам, вы постепенно диска над объектами-призраками в вашей информации.

Answer 6

«Прежде всего, вам нужно понять историю методологии проектирования сущностей, а также понять слово« реляционная »в системах управления реляционными базами данных (РСУБД)».

Могу ли я предложить вежливо, чтобы вы впервые получили ПОЛЬЗОВАТЕЛЯ ОБРАЗОВАНИЕМ по этим же предметам, прежде чем приводить других людей в ошибочные убеждения? Я отвечу на два худших из ваших глупостей ниже.

«Согласно принципам реляционной методологии, каждый объект должен иметь только одно и единственное средство для его идентификации».

Это самая большая дерьмо, которую я когда-либо слышал, когда-либо возникали вокруг реляционных данных. Реляционная модель не ограничивает «сущность», как вы ошибочно называете ее, чтобы иметь точное количество ключей. Любой «объект» может иметь любое количество ключей, а ключ EACH - по определению его самого свойства «уникальных строк», действительного кандидата для любых целей «идентификации». Выбор наиболее полезного/подходящего для использования в определенных контекстах (внешние ключи в ссылках на таблицы, например), является проблемой дизайна, и реляционной модели нечего сказать о таких вещах.

«Следовательно, СУБД« R »пытается облегчить моделирование отношений сущностей».

Документ Кодда «Реляционная модель даты для крупных банков данных общего пользования», которая знаменует рождение реляционной модели, предшествует изобретению E-R на несколько лет. Так сказать, что реляционная модель пытается облегчить моделирование концепций E-R, имеет ПОЛНОСТЬЮ в обратном направлении и ничего, кроме проявления собственного полного и полного незнания «истории», о которой вы говорили в своем собственном ответе.

Answer 7

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