Можно ли использовать символьные значения для первичных ключей?

Question

Есть ли прирост производительности или лучшие практики при использовании полей уникальных числовых идентификаторов в таблице базы данных по сравнению с использованием символьных полей?

Например, если бы у меня было две таблицы:

спортсмен

id ... 17 , имя ... Рики Хендерсон , teamid ... 28

команда

teamid ... 28 , teamname ... Окленд

Таблицу атлетов с тысячами игроков было бы легче читать, если бы teamid был, скажем, «OAK» или «SD» вместо «28» или «31». Давайте считать само собой разумеющимся, что значения teamid останутся уникальными и непротиворечивыми в форме символов.

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

Пожалуйста, игнорируйте аргумент нормализации, так как эти таблицы более сложные, чем пример.

Answer 1

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

Answer 2

Текст в порядке, по всем причинам, которые вы упомянули.

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

Answer 3

Я просто собираюсь покататься с твоим примером. Даг прав, когда говорит, что с текстом все в порядке. Даже для базы данных среднего размера (~ 50 гигабайт), имеющей трехбуквенный код, первичный ключ не убьет базу данных. Если это облегчает разработку, уменьшает количество объединений в другой таблице, и это поле, в которое пользователи будут вводить текст ... Я говорю, пойдите для этого. Не делайте этого, если это просто аббревиатура, которую вы показываете на странице, или потому что это делает таблицу атлетов красивой. Я думаю, что ключевым является вопрос «Это код, который пользователь вводит, а не просто выбирает из списка?»

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

Answer 4

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

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

Answer 5

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

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

Чтобы удовлетворить вышесказанное, но сделать базу данных доступной для чтения,

• использовать числовое поле в качестве первичного ключа

• немедленно создает представление Athlete_And_Team, которое объединяет таблицы Athlete и Team

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

Answer 6

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

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

У вас всегда может быть другой столбец для хранения team_code или чего-то еще для «OAK» и «SD». Также

Answer 7

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