Дори ако вашето потребителско име е уникално, има няколко предимства да имате допълнителна колона с идентификатор, вместо да използвате varchar като основен ключ.
-
Някои хора предпочитат да използват колона с цяло число като първичен ключ, за да служи като сурогатен ключ, който никога не трябва да се променя, дори ако други колони подлежат на промяна. Въпреки че нищо не пречи и естествен първичен ключ да бъде променлив, ще трябва да използвате каскадни ограничения на външния ключ, за да гарантирате, че външните ключове в свързаните таблици се актуализират в синхрон с всяка такава промяна.
-
Първичният ключ е 32-битово цяло число вместо varchar може да спести място. Изборът между колона с външен ключ int или varchar във всяка друга таблица, която препраща към вашата потребителска таблица, може да бъде основателна причина.
-
Вмъкването в индекса на първичния ключ е малко по-ефективно, ако добавите нови редове в края на индекса, в сравнение с вклиняването им в средата на индекса. Индексите в MySQL таблиците обикновено са B+Tree структури от данни и можете да ги проучите, за да разберете как се представят.
-
Някои рамки на приложения предпочитат конвенцията, че всяка таблица във вашата база данни има колона с първичен ключ, наречена
id, вместо да използвате естествени ключове или съставни ключове. Следването на такива конвенции може да направи определени задачи по програмиране по-лесни.
Нито един от тези проблеми не нарушава сделката. Освен това има предимства при използването на естествени ключове:
-
Ако търсите редове по потребителско име по-често, отколкото по идентификатор, може да е по-добре да изберете потребителското име като първичен ключ и да се възползвате от организираното от индекси хранилище на InnoDB. Направете вашата колона за първично търсене да бъде първичен ключ, ако е възможно, тъй като търсенето на първичен ключ е по-ефективно в InnoDB (трябва да използвате InnoDB в MySQL).
-
Както забелязахте, ако вече имате уникално ограничение за потребителско име, изглежда загуба на място за съхранение да поддържате допълнителна колона с идентификатор, от която не се нуждаете.
-
Използването на естествен ключ означава, че външните ключове съдържат стойност, която може да се чете от човека, вместо произволен целочислен идентификатор. Това позволява на заявките да използват стойността на външния ключ, без да се налага да се присъединяват обратно към родителската таблица за "реалната" стойност.
Въпросът е, че няма правило, което да покрива 100% от случаите. Често препоръчвам да държите опциите си отворени и да използвате естествени ключове, съставни ключове и сурогатни ключове дори в една база данни.
Разглеждам някои проблеми със сурогатните ключове в главата „Изисква се идентификационен номер“ в моята книга SQL Antipatterns:Избягване клопките на програмирането на бази данни .
