MySQL-升级主键？

Question

I don't really know how to title this. The thing is i'm a begginer with databases in general and i was wondering if this is a good habit.

So i have some tables in my DB similar to this ones:

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

Is it ok to add AAA's primary key in CCC for "faster accessibility" since i could access through BBB?

Answer 1

The short answer is: Don't do this. You would store data redundantly which may some time lead to errors - what if sudenly a CCC record with id_aaa_AAA = 1 points to a BBB record with id_aaa_AAA = 2?

The long answer is: There are natural keys and artificial (technical) keys...

Often you have natural keys identifying an entity (such as an employee number, an international item number, etc.). Here is a database of companies, employees and sales. The bold columns are the natural keys, which can be used as primary keys for the tables:

• company ( iln , company_name, ...)

The ILN (International Location Number) uniquely identifies a company.

• employee ( iln, employee_no , employee_name, ...)

An employee has an employee number in their company. But it's only unique in combination with the company. (Ie an employee with #123 in company A is someone else than employee #123 in company B of course.)

• sales ( iln, employee_no, year , total)

How much did an employee sell in a year? A record is identified by ILN + employee number to identify the employee plus the year.

Now many people prefer to design a database with technical IDs, because they find the concept more flexible, and often there are entities that simply have no natural key (eg an address is only identified by the sum of all its components, so you'd prefer to create an artificial ID to reference it in other tables). Here is the same database with technical IDs:

• company ( company_id , iln, company_name, ...)
• employee ( employee_id , employee_no, employee_name, company_id, ...)
• sales ( sales_id , employee_id, year, total)

Here each table has a unique technical ID, which is usually the primary key. (Of course you would also have a unique constraint on company(iln) , on employee(employee_no, company_id) and on sales(employee_id, year) still.) There is no redundancy, so the ILN is stored in table company only. If you want the sum of sales for a company in 2015, you'll have to go through all the tables accordingly.

With the aforementioned natural keys you wouldn't. You'd have the ILN in all tables and it still wouldn't be redundant, as it is part of the key of all tables (ie if you removed the ILN from employee or sales, you wouldn't know which employee a record refers to). Here you'd only access the sales table in order to get the sum of sales for a company in 2015.

I find working with natural keys more comfortable, but it takes some time to design such a database properly, and often you'd still have to invent keys, as for adresses, as mentioned. But data access is often more straight-forward and data consistency is guaranteed even with deep hierarchies, which technical IDs cannot provide.

So the long answer is: Decide whether you want to use natural keys.

Answer 2

Try to store as little data a possible in your data base (ie normalize your data).

Having the redundant information in table CCC will only come back to haunt you. If you update a row in BBB to reference a new value in AAA you will then be obliged to update all rows in CCC that reference the row in BBB as well. In this simple example not too big a deal, but once you grow beyond 5 tables this can become very messy and hard to keep track of.