3 ms·
I disagree. See http://spyced.blogspot.com/2006/07/single-column-primary-keys-should-be.html http://spyced.blogspot.com/2006/07/single-column-primary-keys-shoul
by inklesspen 20y ago
I disagree. See http://spyced.blogspot.com/2006/07/single-column-primary-keys-should-be.html http://spyced.blogspot.com/2006/07/single-column-primary-keys-should-be.html
Particularly the three-part series.
Multiple-columns can be hard to deal with. But duplicate rows because you're using an autoincrement integer as your pk are also a pain in the ass. Measure twice, cut once.
- damien 20y agoA primary key is really just the combination of the unique and not-null constraints. My preferred way of handling this is to have a surrogate key as the primary key (for performance and general ease-of-use), but also apply multi-column unique constraints on the natural key to enforce data integrity. The main place where I don't use a surrogate key is for many-to-many join tables (which I think is the common practice).
- run4yourlives 20y agoI think your point is valid, but I'm not seeing the instance where a duplicate rows couldn't easily be identified as being exactly that. I suppose in a fully normalized world of enterprise db architecture this could be an issue, but most real world applications aren't built that way. In reality, speed is key, models are simple and normalized data is usually the bottleneck, and as such, de-normalized PDQ. I know the theory is whack and risks problems, but reality pays the bills in most cases, so it wins.