Hacker News Reader

I disagree. See 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.

View on HN

A 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).

I 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.

Reply on news.ycombinator.com