News for hackers. Stuff that matters.
Re:DHH: we're already overloaded with connectivity by inklesspen on Monday April 02, 2007 @12:59PM (#8248)
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.

Re:DHH: we're already overloaded with connectivity by RyanGWU82 on Monday April 02, 2007 @01:36PM (#8263)
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.

Re:DHH: we're already overloaded with connectivity by inklesspen on Monday April 02, 2007 @01:52PM (#8267)
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.

Re:DHH: we're already overloaded with connectivity by run4yourlives on Monday April 02, 2007 @01:06PM (#8249)
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.
Re:DHH: we're already overloaded with connectivity by inklesspen on Monday April 02, 2007 @01:25PM (#8259)
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.

Re:DHH: we're already overloaded with connectivity by damien on Monday April 02, 2007 @01:58PM (#8269)
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).
Re:DHH: we're already overloaded with connectivity by run4yourlives on Tuesday April 03, 2007 @12:36PM (#8556)
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.