http://www.jqueryin.com/2009/04/06/innodb-composite-keys-and-on-duplicate-key/ A web development blog focusing on PHP, MySQL, Javascript, jQuery, and CSS. Thu, 26 Jan 2012 14:32:59 +0000 hourly 1 http://wordpress.org/?v=3.0.1 http://www.jqueryin.com/2009/04/06/innodb-composite-keys-and-on-duplicate-key/comment-page-1/#comment-20 cballou Tue, 16 Mar 2010 13:40:49 +0000 http://www.jqueryin.com/wordpress/?p=3#comment-20 The choice to store an auto incrementing key is that I have always considered it good practice to store auto incrementing keys for nearly all tables (with the exception of pivot tables) because it allows for easier migrations in the event my site's overall table structure need to undergo a drastic change. To be quite honest, looking back at the code, I can't actually pinpoint why I had decided to not use a composite key with a leftmost prefix of <strong>photosets.photoset_id</strong> in favor of <strong>photosets.id</strong>. If I had to do it all over again, I probably would have gone with PRIMARY KEY(photoset_id, id). Hindsight is always great though, right? The choice to store an auto incrementing key is that I have always considered it good practice to store auto incrementing keys for nearly all tables (with the exception of pivot tables) because it allows for easier migrations in the event my site’s overall table structure need to undergo a drastic change. To be quite honest, looking back at the code, I can’t actually pinpoint why I had decided to not use a composite key with a leftmost prefix of photosets.photoset_id in favor of photosets.id. If I had to do it all over again, I probably would have gone with PRIMARY KEY(photoset_id, id). Hindsight is always great though, right?

]]> http://www.jqueryin.com/2009/04/06/innodb-composite-keys-and-on-duplicate-key/comment-page-1/#comment-19 Alok Tue, 16 Mar 2010 13:17:51 +0000 http://www.jqueryin.com/wordpress/?p=3#comment-19 Interesting… Why did you not make id your primary key? The difference is that the primary key is copied to all other indexes in innodb, and a varchar(50) field is bigger than an unsigned int. Minor point: a composite primary key usually implies that neither field alone is unique, but in your case it looks like you have two keys which are unique on their own. For example, if you had PRIMARY KEY (id, photoset_id), it would only count as a duplicate if you inserted a row that matched on both values – having a composite primary key is not the same as having two separate unique indexes, just like UNIQUE(id), UNIQUE(photoset_id) is not the same as UNIQUE(id, photoset_id). Interesting… Why did you not make id your primary key? The difference is that the primary key is copied to all other indexes in innodb, and a varchar(50) field is bigger than an unsigned int. Minor point: a composite primary key usually implies that neither field alone is unique, but in your case it looks like you have two keys which are unique on their own. For example, if you had PRIMARY KEY (id, photoset_id), it would only count as a duplicate if you inserted a row that matched on both values – having a composite primary key is not the same as having two separate unique indexes, just like UNIQUE(id), UNIQUE(photoset_id) is not the same as UNIQUE(id, photoset_id).

]]>