Я подозреваю, что для разработчика исходной структуры данных требуется терапия Стивена А. Лоу с помощью свернутой газеты.

Кстати, GUID в качестве первичного ключа может снизить производительность. Я бы не рекомендовал это.

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

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

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

Естественный ключ, если он доступен, обычно лучше. Итак, если datetime / char однозначно идентифицирует строку, и обе части значимы для строки, это прекрасно.

Если имеет значение только дата и время, а символ просто прикреплен, чтобы сделать его уникальным, тогда вы можете просто использовать поле идентификации.

Вы должны использовать «составной» или «составной» первичный ключ, состоящий из нескольких полей.

Это вполне приемлемое решение, перейдите по здесь для получения дополнительной информации :)

Я тоже всегда использую столбец числового идентификатора. В оракуле я использую число (18,0) без реальной причины выше числа (12,0) (или любого другого типа int, а не long), может быть, я просто не хочу беспокоиться о том, чтобы получить несколько миллиардов строк в дб!

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

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

Мы выполняем множество объединений, и составные первичные ключи только что снизили производительность. Простые int или long решают многие проблемы, даже если вы вводите второй ключ-кандидат, но гораздо проще и понятнее объединиться в одном поле, а не в трех.

Я всегда использую автономный номер или поле идентификации.

Я работал с клиентом, который использовал SSN в качестве первичного ключа, а затем из-за правил HIPAA был вынужден перейти на «MemberID», что вызвало массу проблем при обновлении внешних ключей в связанных таблицах. Соблюдение единого стандарта столбца идентичности помогло мне избежать подобной проблемы во всех моих проектах.

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

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

Это старая дискуссия. Я предпочитаю суррогатные ключи в большинстве ситуаций.

Но отсутствию ключа нет оправдания.

RE: РЕДАКТИРОВАТЬ

Да, по этому поводу много споров: D

Я не вижу очевидных преимуществ естественных ключей, кроме того факта, что они являются естественным выбором. Вы всегда будете думать в Имя, SocialNumber - или что-то в этом роде - вместо idPerson.

Суррогатные ключи - это ответ на некоторые проблемы, с которыми сталкиваются естественные ключи (например, распространение изменений).

Когда привыкаешь к суррогатным матерям, это кажется более чистым и управляемым.

Но в конце концов вы обнаружите, что это всего лишь вопрос вкуса или мышления. Люди «думают лучше» с естественными ключами, а другие - нет.

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

• Штаты США: я бы выбрал state_code (TX для Техаса и т. д.), А не state_id = 1 для Техаса.
• Сотрудники: Обычно я создаю искусственный идентификатор employee_id, потому что трудно найти что-то еще, что работает. SSN или эквивалент могут работать, но могут возникнуть проблемы, например, с новым участником, который еще не предоставил свой SSN.
• История зарплат сотрудников: (employee_id, start_date). Я бы нет создал искусственный employee_salary_history_id. Какой смысл это будет (кроме "глупая последовательность")

Везде, где используются искусственные ключи, вы всегда должны объявлять уникальные ограничения для естественных ключей. Например, используйте state_id, если необходимо, но тогда вам лучше объявить уникальное ограничение для state_code, иначе вы обязательно в конечном итоге получите:

state_id    state_code   state_name
137         TX           Texas
...         ...          ...
249         TX           Texas

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

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

Если вы действительно хотите прочитать всю эту многовековую дискуссию, поищите «естественный ключ» в Stack Overflow. Вы должны вернуться на страницы с результатами.

Я соблюдаю несколько правил:

1. Первичные ключи должны быть настолько малы, насколько это необходимо. Предпочитайте числовой тип, потому что числовые типы хранятся в гораздо более компактном формате, чем символьные форматы. Это связано с тем, что большинство первичных ключей будут внешними ключами в другой таблице, а также будут использоваться в нескольких индексах. Чем меньше ваш ключ, тем меньше индекс, тем меньше страниц в кеше вы будете использовать.
2. Первичные ключи никогда не должны меняться. Об обновлении первичного ключа не может быть и речи. Это связано с тем, что он, скорее всего, будет использоваться в нескольких индексах и использоваться в качестве внешнего ключа. Обновление одного первичного ключа может вызвать волновой эффект изменений.
3. НЕ используйте «первичный ключ проблемы» в качестве первичного ключа логической модели. Например, номер паспорта, номер социального страхования или номер контракта сотрудника в качестве «первичного ключа» может измениться в реальных ситуациях.

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

Для меня естественные и искусственные ключи - это вопрос того, сколько бизнес-логики вы хотите использовать в своей базе данных. ИНН (SSN) - отличный пример.

«Каждый клиент в моей базе данных будет и должен иметь SSN». Бам, готово, сделай это первичным ключом и покончим с этим. Просто помните, когда ваше бизнес-правило меняется, вы сжигаетесь.

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

Я ищу естественные первичные ключи и использую их, где могу.

Если естественные ключи не могут быть найдены, я предпочитаю GUID, а не INT ++, потому что SQL Server использует деревья, а всегда добавлять ключи в конец деревьев - это плохо.

В таблицах со связями «многие ко многим» я использую составной первичный ключ внешних ключей.

Поскольку мне посчастливилось использовать SQL Server, я могу изучать планы выполнения и статистику с помощью профилировщика и анализатора запросов и очень легко узнавать, как работают мои ключи.

GUID можно использовать в качестве первичного ключа, но вам нужно создать правильный тип GUID, чтобы он работал хорошо.

Вам необходимо создать COMB GUID. Хорошая статья об этом и статистика производительности Стоимость GUID в качестве первичных ключей.

Также некоторый код для создания COMB GUID в SQL находится в Уникальный идентификатор против идентичности (архив).

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

Допустим, у нас есть эти таблицы и столбцы:

Company:
  CompanyId   (primary key)

CostCenter:
  CompanyId   (primary key, foreign key to Company)
  CostCentre  (primary key)

CostElement
  CompanyId   (primary key, foreign key to Company)
  CostElement (primary key)

Invoice:
  InvoiceId    (primary key)
  CompanyId    (primary key, in foreign key to CostCentre, in foreign key to CostElement)
  CostCentre   (in foreign key to CostCentre)
  CostElement  (in foreign key to CostElement)

Если последний бит не имеет смысла, Invoice.CompanyId является частью двух внешних ключей, одного для таблицы CostCentre и одного для таблицы CostElement. Первичный ключ - (InvoiceId, Идентификатор компании).

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

Чем меньше шансов облажаться, тем лучше.

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

• Идентификатор строки (GUID)
• Создатель (строка; по умолчанию используется имя текущего пользователя (SUSER_SNAME() в T-SQL))
• Создано (DateTime)
• Отметка времени

Идентификатор строки имеет уникальный ключ для каждой таблицы и в любом случае автоматически генерируется для каждой строки (и разрешения не позволяют никому редактировать ее), и разумно гарантируется, что он будет уникальным для всех таблиц и баз данных. Если какой-либо системе ORM нужен единственный ID-ключ, то его следует использовать.

Между тем, настоящий ПК, если возможно, является естественным ключом. Мои внутренние правила выглядят примерно так:

• Люди - используйте суррогатный ключ, например ИНТ. Если он внутренний, приемлемым выбором будет GUID пользователя Active Directory.
• Таблицы поиска (например, StatusCodes) - используйте короткий код CHAR; его легче запомнить, чем INT, и во многих случаях бумажные формы и пользователи также будут использовать его для краткости (например, Status = «E» для «Просрочено», «A» для «Утверждено», «NADIS» для «Асбест не обнаружен. В образце »)
• Связывание таблиц - комбинация FK (например, EventId, AttendeeId)

Таким образом, в идеале вы получите естественный, понятный и запоминающийся ПК и удобный для ORM GUID с одним идентификатором для каждой таблицы.

Предостережение: базы данных, которые я поддерживаю, имеют тенденцию к 100 000 записей, а не к миллионам или миллиардам, поэтому, если у вас есть опыт работы с более крупными системами, который противоречит моему совету, не стесняйтесь игнорировать меня!

Я избегаю использования естественных ключей по одной простой причине - человеческая ошибка. Хотя естественные уникальные идентификаторы часто доступны (SSN, VIN, номер счета и т. д.), Для их правильного ввода требуется человек. Если вы используете SSN в качестве первичного ключа, кто-то заменяет пару чисел во время ввода данных, и ошибка не обнаруживается сразу, тогда вам придется изменить свой первичный ключ.

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

Что особенного в первичном ключе?

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

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

• В стороне: к сожалению, побочный эффект большинства разрабатываемых баз данных и разработан прикладными программистами (которыми я иногда являюсь) что то, что лучше всего подходит для приложения или фреймворка приложения, часто управляет выбором первичного ключа для таблиц. Это приводит к целому и Ключи GUID (так как они просты в использовании для фреймворков приложений) и монолитные конструкции столов (так как они сокращают количество приложений объекты инфраструктуры, необходимые для представления данных в памяти). Эти решения по проектированию базы данных, основанные на приложениях, приводят к значительным данным проблемы согласованности при использовании в большом масштабе. Фреймворки приложений спроектированные таким образом, естественно, приводят к созданию таблиц за раз. «Частичные записи» создаются в таблицах, и данные заполняются с течением времени. Взаимодействие с несколькими таблицами избегается или при использовании вызывает несогласованность данные, когда приложение работает некорректно. Эти конструкции приводят к данным, которые не имеют смысла (или трудны для понимания), данные распространяются над таблицами (вам нужно посмотреть на другие таблицы, чтобы понять текущая таблица) и дублированные данные.

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

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

Сказав это, я благодарен за множество плохо спроектированных баз данных, которые существуют сегодня на предприятиях (чудовища с бессмысленным суррогатным ключом-данными-поврежденными-1NF), потому что это означает, что людям, которые понимают, как правильно проектировать базы данных, предстоит бесконечный объем работы. . Но, к сожалению, иногда это заставляет меня чувствовать себя Сизифом, но держу пари, что у него было чертовски 401k (до крушения). Держитесь подальше от блогов и веб-сайтов по важным вопросам проектирования баз данных. Если вы разрабатываете базы данных, найдите CJ Date. Вы также можете сослаться на Celko для SQL Server, но только если сначала зажмете нос. Со стороны Oracle ссылка на Тома Кайта.

Помимо всех этих хороших ответов, я просто хочу поделиться хорошей статьей, которую я только что прочитал, Великие дебаты о первичных ключах.

Процитирую несколько моментов:

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

• Первичный ключ должен однозначно идентифицировать каждую запись.
• Значение первичного ключа записи не может быть нулевым.
• Первичная пара "ключ-значение" должна существовать при создании записи.
• Первичный ключ должен оставаться стабильным - вы не можете изменять поля первичного ключа.
• Первичный ключ должен быть компактным и содержать минимально возможное количество атрибутов.
• Значение первичного ключа изменить нельзя.

Естественные ключи (как правило) нарушают правила. Суррогатные ключи соответствуют правилам. (Вам лучше прочитать эту статью, она того стоит!)

Вот мое собственное практическое правило, к которому я пришел после более чем 25-летнего опыта разработки.

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

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

Наличие первичного ключа с одним значением делает выполнение UPSERT очень простым.

• Отдавайте предпочтение нескольким индексам для отдельных столбцов, а не многостолбцовым индексам. Например, если у вас есть ключ из двух столбцов, предпочтите создание индекса для каждого столбца, а не создание индекса из двух столбцов. Если мы создадим ключ с несколькими столбцами для имени + фамилии, мы не сможем выполнять индексированный поиск по фамилии без указания имени. Наличие индексов в обоих столбцах позволяет оптимизатору выполнять индексированный поиск в одном или обоих столбцах независимо от того, как они выражены в предложении WHERE.

• Если ваши таблицы большие, попробуйте разбить таблицу на сегменты на основе наиболее важных критериев поиска.

• Если у вас есть таблица со значительным количеством полей Id, рассмотрите возможность удаления всех, кроме первичного ключа, в одну таблицу, которая имеет идентификатор (PK), org_id (FK для исходной таблицы) и столбец id_type. Создайте индексы для всех столбцов в новой таблице и свяжите ее с исходной таблицей. Таким образом, теперь вы можете выполнять индексированный поиск любого количества идентификаторов, используя только один индекс.