Какова лучшая практика для первичных ключей в таблицах?

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

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

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

Между тем, фактический PK является, если это возможно, естественным ключом. Мои внутренние правила - что-то как:

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

Так идеально Вы заканчиваете с естественным, человекочитаемым и незабываемым PK и ORM-дружественным one-ID-per-table GUID.

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

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

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

необходимо генерировать GUID РАСЧЕСКИ. Хорошая статья об этом и статистика производительности Стоимость GUID как Первичные ключи .

Также некоторый код создания GUID РАСЧЕСКИ в SQL находится в Uniqueidentifier по сравнению с идентификационными данными ( архив ) .

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

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

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

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

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

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

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

таблицы On, которые являются many-many связями, я использую составной первичный ключ внешних ключей.

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

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

Это - совершенно приемлемое решение, пойдите сюда для большего количества информации:)

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

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

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

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

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

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

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

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

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

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

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

ThereВґs без проблем в создании Вашего первичного ключа от различных полей, это Естественный Ключ .

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

ThatВґs старое обсуждение. Я предпочитаю суррогатные ключи в большинстве ситуаций.

, Но thereВґs никакое оправдание из-за отсутствия ключа.

РЕ: РЕДАКТИРОВАНИЕ

Да, thereВґs большое противоречие об этом: D

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

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

, Поскольку Вы привыкаете к суррогатам, это кажется более чистым, и управляемым.

, Но в конце, youВґll узнают, что это - просто вопрос вкуса - или мышление-. Люди "передумывают" с естественными ключами и другими donВґt.

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

Скажем, у нас есть эти таблицы и столбцы:

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, CompanyId).

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

, Чем меньше возможностей завинтить, тем лучше.

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

• штаты США: я пошел бы для 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

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

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