CODEWITHSUNDEEP
mysqlsqldatabasedesign-patternsdatabase-design
dawn
dawn

Reputation: 397

Auto incrementing ID as primary key on all tables

I am designing a database for an e-Commerce website which uses MySQL. I have made the list of tables necessary and all the fields necessary for the table. I have a total of 9 tables.

What I have done is include an auto incrementing ID as primary key on all the tables.

All my tables except 2 are normalized to 3NF. Two tables 'users' and 'outlets' are not normalized to 2NF.

Along the way I realized that normalization is cumbersome when using auto incrementing ID as a primary key. As normalization is not strictly required, I want to know if there are any downsides of using auto incrementing ID as primary key on all the tables?

Upvotes: 0

Views: 2610

Answers (5)

Bugz
Bugz

Reputation: 118

I agree with @Arun. Use UUIDs instead of auto incrementing INT IDs. This allows for better caching of DB writes. If you create new records they would require a new ID. If the ID is allocated by the DB then the logic layer must talk to the DB first to get the newly incremented ID. UUIDs can be generated by the logic layer or even the front end without talking to the DB. Yes, it uses more bytes but the fact that you separate your layers from the DB is a win in my books

Upvotes: -1

Rick James
Rick James

Reputation: 142366

I have created a lot of tables in my time. I have used AUTO_INCREMENT in only 1/3 of them. The rest had what seemed like a "perfectly good 'natural' PK", so I went that way.

"Normal Form" is a textbook way to get you started. In real life (in my opinion), NF later takes a back seat to performance and other considerations.

For InnoDB tables, you really should have an explicit PRIMARY KEY (either auto_inc or natural).

A generic pattern where auto_inc slows things down is a many:many mapping table, as Renzo points out, and which I discuss here: http://mysql.rjweb.org/doc.php/index_cookbook_mysql#many_to_many_mapping_table

In InnoDB, the PRIMARY KEY is stored (clustered) with the data, so the index structure (a BTree) occupies virtually no extra space. Each secondary index occupies a separate BTree that implicitly includes the PK column(s).

Upvotes: 1

Arun Vinoth PrecogTechnologies
Arun Vinoth PrecogTechnologies

Reputation: 22846

I recommend using GUID - uniqueidentifier as a Primary Key to overrule any limitations in future.

MSSQL: https://learn.microsoft.com/en-us/sql/t-sql/data-types/uniqueidentifier-transact-sql

MySQL: https://forums.asp.net/t/1458664.aspx?UNIQUEIDENTIFIER+data+type+in+MySql

http://mysqlserverteam.com/storing-uuid-values-in-mysql-tables/

Upvotes: 0

Bill Karwin
Bill Karwin

Reputation: 562631

Your question is tagged for MySQL, so I'll point out that MySQL's InnoDB storage engine uses the primary key as its clustered index for all tables.

It's more efficient to query by the clustered index when possible. But if you have an arbitrary rule that all tables must use an auto-increment primary key even if there is another column or set of columns that could serve as the primary key, and you always run queries searching by those columns and not by the auto-increment column, then you'll never gain the advantage of querying by the clustered index.

Upvotes: 1

Virendra Jadeja
Virendra Jadeja

Reputation: 873

Its good to use auto incrementing ID as primary key in all the table. This will help you to auto indexing data. If you are planning to us any ORM (Doctrine2 as example) you must need primary key for each table.

Upvotes: 1

Related Questions