David
Heinemeier Hansson: The greater the versatility, the higher
the abstraction, the less useful for the specifics.
I’m old enough to remember when relational databases were
controversial. Some of the arguments brought forward at those
times are very reminiscent of the ones being made today.
Meanwhile David’s
The sprint of
ideas before release are making me drool, particularly as I had
an opportunity to discuss a few of them with David at
ETech last
week.
Sadly, I’m not old enough, but I am curious. What was the controversy with relational databases?
Until the early 1980s the performance benefits of the low-level navigational interfaces offered by hierarchical and network databases were persuasive for many large-scale applications, but as hardware became faster, the extra productivity and flexibility of relational systems won the day.
In short, foreign keys eventually won out over physical device addresses.
I may be the only one, but I see an analogy here. Furthermore, sentiments such as these are becoming more prevalent.
On the relational database controversy: Those who have access the IEEExplore may be interested in We Are Sorry to Inform You … by Simone Santini in Computer, vol. 38, no. 12, pp. 128, 126–127, Dec., 2005. It contains a peer review rejection of E.F. Codd’s A Relational Model of Data for Large Shared Data Banks.
My first job with RDBMS was on Sun hardware. On my home computer I was still using hierarchical, it just didn’t have enough oomph to run relational. It was also C all the way, C++ was considered too slow.
How things have changed. Now the biggest bottlenecks are network and storage, the speed of the application is less relevant. What’s always is relevant is the speed in which you can deliver the application, fix bugs, add features.
And we’re no longer bound to one machine. You scale out. If it comes down to four servers and 12 month delivery, or five servers and 3 months delivery, I’d go with 3 months.