4 ms·

But that is a defense of ORMs, not using ORMs for NoSQL solutions. The value of document stores for me is that I don't have to worry about JOINs or normalizatio

by m0th87 17y ago

But that is a defense of ORMs, not using ORMs for NoSQL solutions. The value of document stores for me is that I don't have to worry about JOINs or normalization - and thus the layer of abstraction between the object oriented system and the document store is no longer necessary. 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.

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 ago
  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.

by m0th87 17y ago

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 ago
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.