3 ms·
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 decisi
by wkornewald 17y ago
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.
- m0th87 17y agoMaybe 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.