MySQL - Эскалация первичных ключей?

Question

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

Так у меня есть несколько таблиц в моей БД, подобные этим те:

create table AAA(
id_aaa int not null auto_increment, 
primary key (id_aaa) 
); 

create table BBB(
id_bbb int not null auto_increment, 
id_aaa_AAA int not null, 
primary key (id_bbb), 
foreign key (id_aaa_AAA) references AAA (id_aaa) 
); 

create table CCC(
id_ccc int not null auto_increment, 
id_aaa_AAA int not null, 
id_bbb_BBB int not null, 
primary key (id_ccc), 
foreign key (id_aaa_AAA) references AAA (id_aaa), 
foreign key (id_bbb_BBB) references BBB (id_bbb) 
); 

ERD:

AAA (1-n) BBB (1-n) CCC 

Это нормально, чтобы добавить первичный ключ AAA в CCC для «более быстрой доступности» Так как я может получить доступ через BBB?

Answer 1

Короткий ответ: не делайте этого. Вы будете хранить данные избыточно, что может привести к некоторым ошибкам - что если sudenly запись CCC с id_aaa_AAA = 1 указывает на запись BBB с id_aaa_AAA = 2?

Длинный ответ: Есть естественные ключи и ключи искусственные (технические) ...

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

• компания (ИОСА, company_name, ...)

ИОС (Международный адресный номер) однозначно идентифицирует компанию.

• сотрудник (ИОС, employee_no, employee_name, ...)

Работник имеет номер сотрудника в их компании. Но это только уникально в сочетании с компанией. (Т.е. сотрудник с № 123 в компании А кто-то еще, чем работник # 123 в компании B конечно.)

• продаж (ИОС, employee_no, год, всего)

Сколько Через год работник продал? Запись идентифицируется по номеру ILN + для идентификации сотрудника плюс год.

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

• компания (company_id, ИОС, COMPANY_NAME, ...)
• сотрудник (EMPLOYEE_ID, employee_no, employee_name, company_id, ...)
• продаж (sales_id, eMPLOYEE_ID, год, общее число)

Здесь каждая таблица имеет уникальный технический идентификатор, который обычно является первичным ключом. (Конечно, у вас также было бы уникальное ограничение на company(iln), на employee(employee_no, company_id) и на sales(employee_id, year).) Нет избыточности, поэтому ILN хранится только в столовой компании. Если вам нужна сумма продаж для компании в 2015 году, вам придется пройти через все таблицы соответственно.

С вышеупомянутыми естественными ключами вы бы этого не сделали. У вас должен быть ILN во всех таблицах, и он все равно не будет избыточным, поскольку он является частью ключа всех таблиц (т. Е. Если вы удалили ILN от сотрудника или продаж, вы не знали бы, к какому сотруднику относится запись к). Здесь вы получите доступ к таблице продаж, чтобы получить сумму продаж для компании в 2015 году.

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

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

Answer 2

Попробуйте сохранить как можно меньше данных в вашей базе данных (т.е. нормализуйте свои данные).

Имея избыточную информацию в таблице, CCC только вернется, чтобы преследовать вас. Если вы обновите строку в BBB, чтобы ссылаться на новое значение в AAA, вам будет необходимо обновить все строки в CCC, которые также ссылаются на строку в BBB. В этом простом примере не слишком большая сделка, но как только вы вырастите более 5 таблиц, это может стать очень грязным и трудно отслеживать.