Путаница с первичным ключом - PullRequest
2 голосов
/ 11 января 2012

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

Ответы [ 3 ]

2 голосов
/ 11 января 2012

Таблица может иметь более одного ключа.Если номер квитанции должен быть уникальным, и вы хотите, чтобы СУБД применяла ключевые зависимости этого атрибута в качестве ограничения целостности данных, тогда да, вы должны сделать это ключом (с уникальностью, реализованной ограничением PRIMARY KEY или UNIQUE или какими-либо механизмами вашей СУБД).обеспечивает).

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

1 голос
/ 11 января 2012

, если ваш номер квитанции содержит только целое число, то, возможно, вы можете сделать поле квитанции-нет как число с автоматическим приращением,

0 голосов
/ 11 января 2012

Если вашей квитанции нет. достаточно сложен - построен с использованием цифр и символов или длиной 20 цифр - лучше использовать суррогатный UserId

Если квитанция No может быть простым целым числом и может быть сгенерирована из БД - лучше использовать UserId и присвоить его значение ReceiptNo

Если ReceiptNo является простым целым числом и идентифицирует пользователя И единственным пользователем - используйте его как PKey.

...