3 ms·
The use of the term “denormalized” suggests to me that it was a query that involved a lot of joins. Which is certainly something that could have been otherwise
by mbreese 6y ago
The use of the term “denormalized” suggests to me that it was a query that involved a lot of joins. Which is certainly something that could have been otherwise addressed with a different design.
Comparing fetching from a normalized design to a denormalized one isn’t really a fair comparison.
- dathinab 6y agoI fear the problem is that the person doesn't do joins but separate sub-queries which then get recombined in RAM in the client. Given the software stack described there is a realistic chance of this happening implicitly due to ORM mappers. But then the way tables don't map well to 1-to-many mappings and joins still returning data in tables this can also be a problem. Especially if a large field get duplicated a lot. RDBMS really should go from 2d-Tables to proper nested types for results IMHO.
- fabian2k 6y agoThat would be nice, though I suspect that it is really much more complicated than it seems. You can emulate this to some extent in Postgres with the various JSON functions and essentially return a tree from a single query. But my experience was that I quickly got to a point where the query plan got really complex and planning time started to dominate.