Backlash starts against 'sexy' databases
Blame your code, not the RDBMS
Customer Success Testimonial: Recovery is Everything
The relational database - a mainstay of enterprise computing for 25 years - has been under siege. New approaches to data storage are threatening the RDBMS and precipitating what database guru Mike Stonebraker and others described recently as a "group grope" to find a new database engine.
This week, though, could mark the beginning of the backlash, with people defending the RDBMS against fashionable, quick-and-dirty products such as Amazon's SimpleDB, Apache's CouchDB, NextDB and Google's App Engine Datastore.
The catalyst appears to be a debate over popular blogging platform and LAMP flagship Wordpress flogging the database twenty times every time you refresh a page, even when there have been no changes to the elements on a page. Coder and Coding Horror blogger Jeff Atwood posited simply: "Doesn't that strike you as a bad idea? Maybe even, dare I say it, sloppy programming?"
Open source developer Jonathan Holland pulled up WordPress for installing a caching plug rather than fixing the problem at hand.
Holland, who said he understands the shortcomings of a relational database but also knows its strengths, concluded: "The bottom line is don't tell me RDMBS can't scale if you can't write a decent query or design a normalized database schema."
Elsewhere, evangelists have been taken to task for hype, by "fawning" and posting comments "verging on satire" in their support of the new wave - specifically, SimpleDB. Todd Hoff praised SimpleDB for eliminating much of the complexity of traditional RDBMS systems by dispensing with tiresome technicalities such as data schema and normalization. He said such things are unnecessary for many web applications.
Defending RDBMS, computer science student Ryan Park listed 10 reasons for avoiding SimpleDB, CouchDB and Google DataStore. Among them: data integrity is not guaranteed, complicated reports and ad hoc queries will require a lot more coding, and relational databases are scalable even with massive data sets.
"Mr. Hoff's supposed advantages are actually serious disadvantages to the paradigm. Before designing your architecture around a database engine like SimpleDB, it's important to consider the reasons not to do so," Park wrote.
He also added a useful reality check to supporters of SimpleDB by pointing out the poster children of Web 2.0 are founded on RDBMS: Facebook and LiveJournal are on MySQL, MySpace on Microsoft's SQL Server, and Salesforce.com uses Oracle.
Backing Park was software architect and technology writer Dennis Forbes, who drew a distinction between "web toys" and big "specialized databases" run by the likes of Amazon. "Until the day you build your own specialized database, an RDBMS is often a suitable choice," Forbes wrote in comments to Park.
It wouldn't be a tech debate, though, without the usual allegations of fanboydom, and so there were counter claims of too much RDBMS love. And such commentators will likely be unsurprised to learn that RDBMS vendor IBM also believes in the continued relevance of RDBMS, saying it has a place in web applications
The RDBMS is certainly facing new challenges, in terms of scale and provisioning.
Pioneers Stonebraker and David DeWitt themselves have argued in favor of replacing RDBMS - apparently putting themselves in the same camp as folks on the front like Holland, who accept RDBMS has limitations but who also recognize that "bad" coding can also create performance and scalability problems.
Such people, though, are taking a wait-and-see instead of an all-or-noting approach, favoring practicality and evolution over revolution.®
Additional reporting by Gavin Clarke
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
COMMENTS
NextDB *is* relational
I have one gripe about NextDB being lumped with non-relational solutions, and that is ....NextDB *is* relational. NextDB supports relationships as first-class constructs. If you don't need a relational model, just don't use relationships, but they are there in NextDB if you need them. I recently attended the Web 2.0 conference and there was a discussion group on all these new flavors of database. I was amazed to hear that with SimpleDB there is no way to do a "count"....I was told you have to retrieve all the records and loop over them to do a count. The developer also described how for each record returned to his server, he had to open a connection back to Amazon to retrieve the result. If your server has to open N+1 connections to retrieve N results it smells like the "N+1 Problem" that existed in the earlier versions of Enterprise Java Beans with Entity Beans. But now each connection is actually going over the internet rather than your LAN, which would reduce performance even more. Food for thought.
I still think RDBMS' would be easier to work with.
@jim a:
I dunno... I can't imagine it being too hard to normalize an object structure like that for a relational database. I've got to believe it'd be easier to do it the DB way than the pure object way... Tables and SQL are so much simpler in my opinion.
It wouldn't take THAT much code. Would it? Most of the plumbing would be in an abstract base class, written once and forgotten. All your child classes would have to implement would be abstract methods that set up SQL and parameters, right? Plus you can do wicked voodoo with stored procedures. How would you do that in an ORM setup?
I still don't get the problem non-RDBMS' are supposed to solve. What's hard? What can't be done in SQL?
Question-mark Paris, because she's confused too. :)
Object DB for complex data
I think the power and popularity of RDBMS is due primarily to the standard query language and efficient indexing which makes those queries fast. If your application does not use those heavily and you want to 'model' your data using complex objects, you might want to consider something else, like an Object database.
For example, we have a very complex Contact object that needs to be simply saved by ID and re-read later; I considered pasting the entire serialized object graph here but it is 1300+ lines and goes 5-6 levels deep (for a single object); here are a few of the hundreds of XPath's to give you some idea of the types of data involved:
BorrowerContact/ContactReminder/birthday/
BorrowerContact/ContactStatus
BorrowerContact/NotesList/Note/created/time/timezone/
BorrowerContact/primaryBorrower/Liabilities/BorrowerCreditScores/BorrowerCreditScore/borrowerCreditScoreType:EXPERIAN
There are also addresses; co-borrowers; assets; etc etc etc.
Here is all the code needed to save this ENTIRE object to db4o (and the code to read it is similar); NO O/R problems here:
String fileName = "TEST.db4o";
ObjectContainer db = Db4o.openFile( fileName );
try {
db.set(contactObject); // That's it ! Your entire object graph is saved.
...
'Normalizing' this object would take a LONG time; and a LOT of code; and make it more difficult to make future changes.
There are also commercial object DB's (Objectify, Intersystems Cache) that provide SQL access to your objects; too bad no open-source projects do a decent job of this (yet?).
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring
