MySQL - Каков правильный метод первичного ключа

Question

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

Любые идеи, помощь/руководство?

Answer 1

Существуют два основных метода выборе primary key:

• Выбор первичного ключа из существующих natural candidate keys.
• Создание surrogate key и установка его в качестве первичного ключа. В отличие от естественного ключа, суррогатный ключ не получается из данных приложения. Это тип ключа, который у вас был с помощью метода автоматического увеличения.

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

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

Answer 2

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

Answer 3

Автоинкрементные идентификаторы и нормализация не связаны (т. Е. Вы можете использовать автоматически увеличивающиеся идентификаторы в де-нормированной базе данных или иметь нормализованную базу данных, которая не использует автоматически увеличивающиеся идентификаторы).

Answer 4

КОМПОЗИТА PK ПОДХОД

drop table if exists users; 
create table users(
user_id int unsigned not null auto_increment primary key, -- clustered auto_inc PK 
username varbinary(32) not null, 
unique key users_username_idx(username) 
)engine=innodb; 

insert into users (username) values ('f00'),('bar'),('bish'),('bash'),('bosh'),('F00'); 

drop table if exists user_friends; 
create table user_friends(
user_id int unsigned not null, 
friend_user_id int unsigned not null, 
primary key (user_id, friend_user_id) -- clustered composite PK 
)engine=innodb; 

insert into user_friends values 
(1,2),(1,3), (2,1),(2,5), (3,5), (4,1),(4,2),(4,3),(4,5),(4,6), (5,4),(5,1); 

большая часть времени я запрашиваю user_friends желающего перечислить все друг для данного пользователя поэтому мои запросы воспользовавшись кластеризированного первичного ключа (user_id, friend_user_id)

select * from user_friends where user_id = 4; -- uses PK index 

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

delete from user_friends where user_id = 4 and user_friend_id = 5; -- uses PK index 

AUTO INC PK ПОДХОД (таблица пользователей остается неизменным)

drop table if exists user_friends; 
create table user_friends(
friend_id int unsigned not null auto_increment primary key, -- clustered auto_inc PK 
user_id int unsigned not null, 
friend_user_id int unsigned not null, 
unique key user_friends_idx (user_id, friend_user_id) -- non clustered secondary index 
)engine=innodb; 

большую часть времени я запрашиваю user_friends хотел перечислить всех друзей для данного пользователя в этом случае я могу Не используйте первичный ключ, и мне нужно создать дополнительный индекс (user_id, friend_user_id). Теперь у меня есть 2 индекса на этой таблице индекс PK , обеспечивающий целостность объекта и вторичный индекс, который помогает оптимизировать мои запросы.

Добавление вторичного индекса связано с его стоимостью.вставки/удаления теперь имеют значение . Обновление 2 индекса по сравнению с одним индексом составного ключа и занимает больше дискового пространства.

select * from user_friends where user_id = 4; -- uses secondary index not PK 

Однако, если я хочу, чтобы удалить друга я могу использовать friend_id PK это упрощает мою логику приложения , как я могу удалить 1 строку легко только с помощью ПК.

delete from user_friends where friend_id = 10; -- uses PK index 

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