Re:Writing a non-relational Django backend
by wkornewald on Tuesday April 06, 2010 @01:07PM
(#1245067)
Well, instead of thinking about normalization you now have to think about denormalization. It's just the other extreme. This isn't really a philosophical decision. Either you want to have an abstraction layer that takes care of these things for you or you want to write your code manually. I prefer the abstraction because it gives me more time to think about the problems that matter.
Maybe I'm dense, but I still don't understand. I'm guessing denormalization means going from relational data to non-relational data. When you're working with a document store, data never has to be normalized, and as a consequence, it never has to be denormalized either.
Take, for instance, getting a user with the first name 'Martha'. In a document store, it might look like:
store.get({first='Martha'})
Whereas in Django's ORM, it might look like: User.objects.filter(first='Martha')
And for reference, the SQL might look like: query("SELECT * FROM User JOIN Preferences ON User.Id=Preferences.UserId WHERE First=%s", 'Martha')
The first two are obviously simpler than the third. But how is the Django ORM inherently superior to the document store's? When your atomic unit is a document, there's no longer a need for Django models.
This is opposed to relational databases, where you generally either go with a DAL if you want to be low-level or an ORM if you're willing to sacrifice some scalability. And the loss in scalability is not comparable to that of going from assembly to a higher level language. ORMs include often unnecessary JOINs and other logarithmic queries whose performance degrades with the size of the data set. With programming languages, performance loss is usually "constant" so it's a much less painful pill to swallow.