Настройка базовой таблицы, является ли целочисленный первичный ключ с автоинкрементом стандартным?

Question

У меня есть веб-приложение, у меня есть концепция пользователей, которая, вероятно, войдет в таблицу пользователей, например:

table: user
username (varchar 32)  |  email (varchar 64)  |  fav_color  |  ...

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

Не уверен, почему это делается, чтобы потом как-нибудь ускорить запросы по внешним ключам? Например, допустим, у меня есть еще одна таблица, например:

table: grades
username (foreign key?)  |  grade

Неэффективно ли использовать имя пользователя в качестве внешнего ключа? Я хочу сделать такие запросы, как:

SELECT FROM grades WHERE username = 'john'

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

SELECT FROM grades WHERE fk_user_id = 20431

Спасибо

Answer 1

То, что вы спрашиваете, является в некоторой степени дизайнерским решением, основанным на суждении отдельного разработчика моделей данных.Лично в этом случае я бы включил первичный ключ с автоинкрементным целым числом.Необычно гарантировать, что имя пользователя (и тем более адрес электронной почты) будет неизменным.Однако вы можете спроектировать свое программное обеспечение так, чтобы один и тот же целочисленный первичный ключ всегда относился к одному и тому же пользователю, независимо от того, что еще может измениться в этой пользовательской записи.ограничение на имя пользователя с индексом, который соответствует ему.Если вы действительно хотите, чтобы адреса электронной почты были уникальными (в основном это решение по деловым требованиям), вы также можете наложить уникальное ограничение на адрес электронной почты.Внешние ключи игнорируются в ядре СУБД по умолчанию в MySQL (к сожалению), поэтому я не буду вдаваться в преимущества с точки зрения моделирования данных.

Редактировать:

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

Answer 2

Мне нравятся целочисленные ключи, потому что:

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

Answer 3

Целочисленные значения в качестве первичного ключа значительно облегчат вашу жизнь в будущем по мере развития вашего приложения.Используйте индекс вашего имени пользователя и / или адреса электронной почты для оптимизации запроса.

Answer 4

Это не обязательно «стандарт» как таковой, но он быстрый, простой, удобный и, как правило, устойчив к изменениям бизнес-ключей.

См. Также: Плюсы и минусы автоинкрементных ключей на каждом столе

Answer 5

Мой совет, после многих лет db-building

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

Реальный мир - это хаотичное место, и как только вы используете PK, вы становитесь склоном.

Просто поверь мне.

(и увеличение скорости тоже).

С уважением, // т

Answer 6

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

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

Answer 7

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