auto increment - nature key vs auto_increment key as the primary key -


my problem nature key , auto_increment integer primary key.

for example, have tables a , b , a_b_relation. , b may object, , a_b_realtion record many many relation of , b.

both , b have own global unique id, such uuid. uuid available user, means user may query or b uuid.

there 2 ways design table's primary key.

  1. use auto_increment integer. a_b_relation reference integer fk.
  2. use uuid. a_b_relation reference uuid fk.

for example, user want query b's info associate a's uuid.

for first case, query flow this:

first, query a's integer primary key uuid `a`.  , then, query b's integer primary key `a_b_relation`.  @ last, query b's info `b`. 

for latter case, flow below:

query b's uuid `a_b_relation` a's uuid.  query b's info `b`. 

so think, latter case more convenient. right? what's shortage of latter case?

according opinion convenience of using either natural key of auto-increment key depends on program solution providing. both methods have pros , cons. best solution understand both key types properly, analyze kind of business solution trying provide , select appropriate primary key type.

natural key column or set of columns can used uniquely identify record in table. these columns contain real data has relationship rest of columns of table.

auto-incremented key, called surrogate key single table column contains unique numeric values can used uniquely identify single row of data in table. these values generated @ run-time when record inserted table , has no relationship rest of data of row.

the main advantage of using natural keys has it's own meaning , requires less joins other tables if used surrogate key require join foreign key table results got natural key.
cannot data required single table , have join table data required. convenient use surrogate key instead of natural key because of time natural keys strings , larger in size surrogate keys , take more time join tables using larger values.

natural key has it's own meaning. when comes searching records more advantageous use natural keys on surrogate keys. time our program logic changes , have change natural key value. difficult , cause cascade effect on foreign key relationships. can overcome problem using surrogate key. since surrogate key not have relationship rest of values of row, changes of logic won't have affect on surrogate key.

likewise, see convenience , inconvenience of using surrogate key or natural key entirely base on solution providing.


Comments

Popular posts from this blog

php - Invalid Cofiguration - yii\base\InvalidConfigException - Yii2 -

How to show in django cms breadcrumbs full path? -

ruby on rails - npm error: tunneling socket could not be established, cause=connect ETIMEDOUT -