Зачем использовать первичный ключ с автоматическим приращением, когда существуют другие уникальные поля?

Question

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

Вот пример таблицы, я создал:

CREATE TABLE users 
(
    uid INT NOT NULL AUTO_INCREMENT, 
    username VARCHAR(60), 
    passhash VARCHAR(255), 
    email VARCHAR(60), 
    rdate DATE, 
    PRIMARY KEY(uid) 
); 

Профессор сказал мне «UID» (идентификатор пользователя) был совершенно бесполезным и ненужным, и я должен был использовать имя пользователя в качестве первичного ключа, так как нет два пользователя могут иметь одинаковое имя пользователя.

Я сказал ему, что мне удобно использовать идентификатор пользователя, потому что, когда я вызываю что-то вроде domain.com/viewuser?id=5, я просто проверяю параметр с помощью: is_numeric($_GET['id']) ... само собой разумеется, что он не был убежден.

Поскольку я видел user_id и другие аналогичные атрибуты (thread_id, comment_id, среди других) на множестве учебных пособий и рассматривает схему базы данных популярного программного обеспечения (например, vbulletin), должно быть много других (более сильных) причин ,

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

Answer 1

автоинкрементные первичные ключи полезны по нескольким причинам:

• Они позволяют дублирующиеся имена пользователей, как на переполнение стека
• Они позволяют имя пользователя (или адрес электронной почты, если это используется для входа в систему), чтобы быть изменен (легко)
• Выбирается, соединения и вставки быстрее, чем VARCHAR первичных ключей, как его гораздо быстрее, чтобы поддерживать числовой индекс
• Как уже упоминалось, проверка становится очень просто: if ((int)$id > 0) { ... }
• санитария ввода тривиальна: $id = (int)$_GET['id']
• Существует гораздо меньше накладных расходов, как внешние ключи не должны дублировать потенциально большие строковые значения

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

Системы с уникальными именами пользователей прекрасно подходят для очень небольшого числа пользователей, но Интернет оказал им принципиально нарушенную работу. Когда вы рассматриваете огромное количество людей с именем «john», которые могут взаимодействовать с веб-сайтом, смешно требовать от каждого из них использования уникального отображаемого имени. Это приводит к ужасной системе, которую мы так часто видим со случайными цифрами и буквами, украшающими имя пользователя.

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

Answer 2

Если имя пользователя является первичным ключом, а пользователь меняет свое имя пользователя, вам необходимо обновить все таблицы, содержащие ссылки на внешние ключи для таблицы users.

Answer 3

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

Answer 4

Например, целочисленный поиск (? Id = 5) намного быстрее и имеет более высокую мощность, чем строковый поиск (? Username = bob). Другой пример: uid is auto_increment, поэтому вам не нужно вставлять его явно, но он будет автоматически увеличиваться в каждом запросе на вставку.

PS: Ваш проф тааак неправильно об этом: D

Answer 5

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

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

Lets face it, большинство проектов не собираются расширять , что много, но вы действительно хотите рискнуть головной болью 12 месяцев в будущем, когда вы сможете соответствовать хорошим стандартам программирования сейчас?

Answer 6

Мы используем идентификатор для предотвращения дублирования данных, и это может сделать некоторые проакции не сложными (если мы хотим обновить или удалить данные), это проще, если мы используем ID.

Если вы не хотите использовать ID, вы можете использовать другие поля. но не забудьте сделать их УНИКАЛЬНЫМИ. он может сделать ваши данные превентивными из данных дублирования.

другой способ за пределами ОСНОВАНИЯ UNIQUE.

Answer 7

Я иду со всеми ответами выше. Я бы сказал, что идентификатор легко реализовать, и когда дело доходит до индексации, Int всегда предпочтительнее по сравнению с varchar. Ваш профессор должен знать лучше, почему он сказал бы, что нет, чтобы Int id был выше меня!

Answer 8

Обычно это называется surrogate key, и у него много преимуществ. Один из них изолирует ваши отношения с базой данных из данных приложения. Более подробную информацию и соответствующие недостатки можно найти по ссылке wiki, приведенной выше.

Answer 9

Поскольку идентификатор пользователя должен быть уникальным (не может быть дублирован) & иногда является индексом.

Answer 10

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

Answer 11

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

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

Искреннее спасибо за отправку вашего SQL DDL, это очень полезно, но большинство из них не беспокоятся о SO.

Используя таблицу, я могу это сделать:

INSERT INTO users (username) VALUES (NULL); 
INSERT INTO users (username) VALUES (NULL); 
INSERT INTO users (username) VALUES (NULL); 
INSERT INTO users (username) VALUES (NULL); 
INSERT INTO users (username) VALUES (NULL); 

Каких результаты в этом:

SELECT uid, username, passhash, email, rdate 
FROM users; 

uid username passhash email rdate 
1  <NULL>  <NULL>  <NULL> <NULL> 
2  <NULL>  <NULL>  <NULL> <NULL> 
3  <NULL>  <NULL>  <NULL> <NULL> 
4  <NULL>  <NULL>  <NULL> <NULL> 

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

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

Answer 12

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