Web Operations: Keeping the Data On Time, a new O’Reilly book, arrived in last week’s mail. I have reviewed in http://philip.greenspun.com/book-reviews/web-operations
Great review. On programmer antipathy towards SQL – modern web stacks are so large and complicated, that developers simply have no “energy” left for SQL and the payoffs for doing “correct” SQL aren’t as great as the payoffs elsewhere. We accept any and all things that (seem to) hide the complexity of the database.
For example, I bet it was months before the db deficiencies creeped up on mitgenius.com’s ruby on rails site (reference: http://philip.greenspun.com/blog/2009/05/18/ruby-on-rails-and-the-importance-of-being-stupid/). But I bet he was able to get a site the *looked* like it worked out the door in record time with the help of rails, which hid a bunch of stuff that he didn’t want to understand. By the time these problems showed up, it became your problem, not his.
You should check out a “modern” web stack to see what today’s programmers are up against. Learn Ruby/Rails/Memcached/Ajax/etc to get a better understanding of the complexity of today’s programming vs the olden days of running tcl scripts on AOLServer. If anything is gonna get dropped out of that stack, it’s gonna be something the customer doesn’t “see” (rdbms).
I am enjoying this presentation from VoltDB CTO Mike Stonebraker. He is dry, old, slightly boring…and probably right.
• Myth #1: SQL is too slow, so use a lower level interface • Myth #2: I like a K-V interface, so SQL is a non-starter • Myth #3: SQL systems don’t scale • Myth #4: There are no open source, scalable SQL engines • Myth #5: ACID is too slow, so avoid using it • Myth #6: in CAP, choose AP over CA
The review at HighScalability looks good also.
Attikus, I disagree that the antipathy towards SQL is justified by the payoff. For example if you agree with phil that the only significant aspects of Web development are data model, SQL queries and transactions, and page flow design (which I do), you’d probably come up with something that generates most of the glue code (I have). Essentially what you come up with will make (for most common apps) the entire scripting layer obsolete (from programming time perspective).
Ebow Halm,
I did not mean to say this attitude was justified. I was attempting to explain why it’s there.
Also, anything SQL/RDBMS-related is seen as a bit of a second-class citizen amongst typical OO developers. Anything that seems “hides all that stuff” (read: Ruby on Rails) will be eagerly embraced by developers. But the fact remains, you actually do need to be familiar with what’s going on under the hood of all these abstractions to create something that performs well under load.
And by the time problems crop up that smash your pretty abstraction…the developer is long gone….
Great review. On programmer antipathy towards SQL – modern web stacks are so large and complicated, that developers simply have no “energy” left for SQL and the payoffs for doing “correct” SQL aren’t as great as the payoffs elsewhere. We accept any and all things that (seem to) hide the complexity of the database.
For example, I bet it was months before the db deficiencies creeped up on mitgenius.com’s ruby on rails site (reference: http://philip.greenspun.com/blog/2009/05/18/ruby-on-rails-and-the-importance-of-being-stupid/). But I bet he was able to get a site the *looked* like it worked out the door in record time with the help of rails, which hid a bunch of stuff that he didn’t want to understand. By the time these problems showed up, it became your problem, not his.
You should check out a “modern” web stack to see what today’s programmers are up against. Learn Ruby/Rails/Memcached/Ajax/etc to get a better understanding of the complexity of today’s programming vs the olden days of running tcl scripts on AOLServer. If anything is gonna get dropped out of that stack, it’s gonna be something the customer doesn’t “see” (rdbms).
I am enjoying this presentation from VoltDB CTO Mike Stonebraker. He is dry, old, slightly boring…and probably right.
“VoltDB Webinar – SQL Urban Myths”
http://danweinreb.org/blog/voltdb-versus-nosql
• Myth #1: SQL is too slow, so use a lower level interface
• Myth #2: I like a K-V interface, so SQL is a non-starter
• Myth #3: SQL systems don’t scale
• Myth #4: There are no open source, scalable SQL engines
• Myth #5: ACID is too slow, so avoid using it
• Myth #6: in CAP, choose AP over CA
The review at HighScalability looks good also.
Attikus,
I disagree that the antipathy towards SQL is justified by the payoff. For example if you agree with phil that the only significant aspects of Web development are data model, SQL queries and transactions, and page flow design (which I do), you’d probably come up with something that generates most of the glue code (I have). Essentially what you come up with will make (for most common apps) the entire scripting layer obsolete (from programming time perspective).
Ebow Halm,
I did not mean to say this attitude was justified. I was attempting to explain why it’s there.
Also, anything SQL/RDBMS-related is seen as a bit of a second-class citizen amongst typical OO developers. Anything that seems “hides all that stuff” (read: Ruby on Rails) will be eagerly embraced by developers. But the fact remains, you actually do need to be familiar with what’s going on under the hood of all these abstractions to create something that performs well under load.
And by the time problems crop up that smash your pretty abstraction…the developer is long gone….