3 ms·
If you're joining in the application, why use a relational database?
by robertlagrant 3y ago
If you're joining in the application, why use a relational database?
- horse_dung 3y agoThis is so true. If you just want the data then use a different store (e.g. NoSQL) and everything will be quicker, lighter weight and slower to develop…
- paulddraper 3y agoWhat does "lighter weight" mean? Smaller install size? Smaller memory footprint? Schemaless?
- toolz 3y agoJust because you're joining in the application for one code path doesn't mean all of the code paths are doing the same thing. There are certainly valid use-cases for joining in the application because application layer can often times be horizontally scaled more cheaply/easily than the persistence layer. So in a scenario where you have plenty of network IO being under utilized for your database, it's not unimaginable where joining in the application layer would be preferable.
- pard68 3y agoFWIW the article never says to join at the app level. GP read wrong or something. The article says to shift logic to the application.
- robertlagrant 3y agoAh - fair enough. I knew I should've checked the article first before replying!
- OJFord 3y agoThis may start to depend on exactly what you're willing to call relational, but because you still want the schema & foreign key constraints for example enforced in the database, you're just going to do the actual mechanics of joining the data in the application? join_users_and_widgets( run_sql('select * from users where account_id = :1', req.account_id), run_sql('select * from widgets'), ) for example, where the db still enforces that `widgets.owner_id` is a fk to `users.id` say. And `join_users_and_widgets` only has to know the current version of the schema, all rows have the same columns as it were.