this post was submitted on 11 Feb 2024
41 points (93.6% liked)
Programming
17426 readers
49 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
An interesting concept, and I do agree that the post-join cost is something that we can probably safely ignore. But as I was reading it I was curious if a better way to start conceptually approaching the solution is to consider an n+1 table approach where any tables referenced will be returned (filtered to relevant rows and optionally omitting extraneous columns) along with an additional table containing necessary key references and any of the computed aggregates etc... this might shift the select phrase to instead of defining all desired columns to only specifying additionally needed columns.
But... I do have some objections to this concept it seems to place an extremely heavy value on the initial schema that SQL does not and causes difficulties in some scenarios when a single table is joined against multiple times for different purposes. I think it'd become difficult for the front end to decipher and rebuild the relationships without very heavy lifting.
It's a really interesting idea and flips the established return structure on its head in a way I don't hate.