Char (4) в качестве первичного ключа

Question

Классический дизайн таблицы базы данных будет включать tableId int index(1,1) not null, что приведет к автоматическому приращению поля int32 id.

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

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

"admn" - "Administrator"
"edit" - "Editor". 

Затем я могу ссылаться на эти «коды» в своем коде.

Обновление
При написании кода имеет больше смысла видеть User.IsInRole («admin»), а не User.IsInRole (UserRoles.Admin), где Admin - это int, который необходимо обновлять / синхронизировать, если вы когда-либо перестраиваете свою базу данных.

Answer 1

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

Answer 2

Нет. Нет, нет, нет, нет и нет.

Ключи не являются данными. Ключи не имеют значения. Таким образом, когда значение меняется, ключи не меняются.

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

Поскольку нет способа перейти от «admn» к «Aministrator» без поиска, и поскольку настоящее значение «Администратор» находится прямо рядом с «полезным» ключом SEKRET ENKODED, зачем мне смотреть на этот ключ? вместо реальных данных прямо рядом с ними в таблице?

Если вам нужна сокращенная форма, имя, подобное перечислению, или что у вас есть, тогда назовите его и поймите, что это data . Это совершенно приемлемо. create table( id int not null primary key, abbv char(4), name varchar(64));

Но это не ключ, он не хешируется как целочисленный ключ, он требует четырехсимвольного сравнения и поиска нулевого терминатора, чтобы сравнить его с «edtr», в отличие от одного вычитания для сравнения двух целых чисел. Не существует достойного способа генерировать следующий ключ: что будет дальше в последовательности ('admn', 'edtr',?)?

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

Используйте синтетический ключ. Если вам действительно нужно сокращение, сделайте это столбцом атрибута.

Answer 3

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

В чем преимущество использования 'admn' в качестве первичного ключа в этом случае?

Answer 4

Вы сравниваете автоинкремент с фиксированным символом char, но в этом сценарии вам не нужен автоматически инкрементный идентификатор.

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

Answer 5

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

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

Answer 6

Я думаю, что ответ в вашем посте. Ваш пример User.IsInRole ("admin") всегда будет возвращать false, поскольку у вас есть первичный ключ char (4) и вы используете "admn" в качестве ключа для администратора.

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

Answer 7

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

Иногда в таблице нет естественного неизменяемого столбца, и в этом случае полезен суррогат.

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

В противном случае вы вводите сложность для удовлетворения чего-то с минимальной вероятностью случиться.

Это только мое мнение, меня зовут не Кодд или Дата, поэтому не воспринимайте это как Евангелие.

Answer 8

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

http://en.wikipedia.org/wiki/Surrogate_key

Если вы используете «admn» в качестве первичного ключа, то он называется Natural key, и другой класс разработчиков считает, что это лучший метод.

https://en.wikipedia.org/wiki/Natural_key

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

Answer 9

Жесткий код => ссылки на базы данных всегда плохая идея! (За исключением того, что вы установили их перед запуском приложения и т. Д.)

Кроме этого: Должны ли в базе данных действительно выполняться сопоставления от администратора admn =>?

И вы можете хранить только 23 ^ 4- (ключевые слова) записей с varchar4 с алфавитом LATIN 23char.