Hacker News Reader

Comment by inklesspen | Hacker News Reader

Oh, yay, DHH. The same guy who insists that you never need a multiple-column primary key.

I currently work for a company (yeah, yeah; the startup is gonna be next year, once I graduate) that produces software for health care agencies. We're writing the next version of our app in Rails, but the problem is that a significant number of our customers need to be able to use the app out in the boonies. Out where if they're lucky, they have _analog_ cell phone service.

There is a real need for offline capability for webapps; you just don't see it when you keep your eyes on 37Signals-type apps.

View on HN

There is a real need for offline capability for webapps; you just don't see it when you keep your eyes on 37Signals-type apps.

What kind of apps do you think are more suited for this? Just curious.

Well, as I said, my company's app needs it. And if you follow the link to DHH's site, you see many people in the comments talking about their apps that need offline support; companies working with Australian ag businesses, for example.

Another thing might be 30Boxes or whatever favorite calendar app you have. Sure, you can sync the feed to iCal, but you can't do everything off a feed.

He's wrong about he offline app, but he's bang on with the multiple column key. That has caused nothing but heartache for me.

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.

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