(RDBMS) v (¬RDBMS)

My previous post was in response to Keith's writing regarding the possibility of escaping object relational mapping problems by avoiding altogether RDBMS's. The discussion of where and how relational databases are to be used turned out to be a hot topic on the blogosphere* these days, mostly fueled by Tim O'Reilly's nine-part saga on data management in Web 2.0* companies. The three most salient points I got from Tim's posts were: there is a preference for clustering by data partitioning instead of general replication strategies; predictably there also is a preference for open source relational db systems (MySQL being the front-runner); and there is a belief that read-mostly data is better served from flat files (sometimes with sophisticated replication mechanisms) than from RDBMS'. There is a lot of interesting info there, I recommend reading the whole thing.

Speaking of read-mostly data, I found this cool project via Joe Gregorio. It's a relational database system being built at MIT optimzed for this kind of data. Another interesting system for dealing with simple read-mostly data is Google's BigTable, that seeks to achiveve high throughput by adopting of a very simple data model, whithout integrity constraints nor transactional capabilities, structured in a highly distributed and fault-tolerant fashion (as would be expected of google). It also features native data versioning support.

PS: Yes, this post was written in english. At least something approaching what one might call "english"... The short motive is that I just felt like it. The longer one is that I need to practice my english at least as much as I need to practice my portuguese, and writing practice is one of the primary reasons for this blog's existence (yes, I'm a selfish bastard).

* buzzword count: 2. I'll try to do better next time.

Don't forget to use your brain

Keith Braithwaite, one of the postmodern programming guys, wrote this interesting blog post. I tried to comment on the post page but, sadly, my wise and deep words didn't find it's way to the world wide web. So, in the immortal words of the prophet, I'm just gonna have to wing it here.

A reasonable amount of bytes and brain cells have been lost, over the years, on the object-relational mapping battleground. Keith's argument is that many of those casualties could be prevented if developers let go of the RDMS dogma and adopt simpler solutions when possible. If the requirements don't indicate a heavy load of concurrent updates, then there is no need for powerful (and expensive) transactional capabilities. He gives as an example an online shopping web site. Usually, additions and changes to the product catalog don't need to be immediately reflected to the users. Also, the possibility of simultaneous modifications can be negligible here. He proposes* that, in cases like this, the data can be made available in a simple format locally, on the front-end servers. Updates can be periodically pushed from a central database to the front-ends.

The only nit I have to pick with his post is when he talks about queries:

"For instance, if you want to get hold of an object that (you have to know) happens to be backed by the underlying database then what you do is obtain an entry point to the data, and search over it for the object you want. Unlike the navigation that you might expect to do in an object graph, instead you build...queries. (...)"

Yes, building a whole query just to get hold of one object reference is too much trouble and a violation of DRY (parenthesis: this sort of thing eases somewhat this pain, minus all the factories and spurious abstractions). But I think he overlooks a bit the fact that often we really need to do a query. It's frequently part of the problem domain, not the solution domain, to put it in other (more pompous) words.

I view queries as inherently declarative operations (given x information, get me Y more information). As such, they are better expressed through declarative means. So, aCollection select: aBlock in Smalltalk is better than the equivalent for loop in Java. Still in OOland, Evans and Fowler's Specification pattern is even better for more complex cases. Advancing to the logical conclusion, a language specifically designed for searching would be even better. Unfortunatly, SQL falls short of reaching this goal in practice, because of the mess that is integrating it with the rest of the application. Microsoft's linq project is an intriguing technology in this space.

Anyway, what I wanted to point out is that there is no one size fits all software architecture and every project needs to be thought out** by a team who knows what it's doing and isn't afraid to think outside the vendor-supplied box.


* barring possible misunderstandings of my part.
** This is not a defense of BDUF