I'd like to discuss your thoughts on relational and non-relational databases (mainly) and their use cases. I'm more accustomed to fixed column schemas from relational dbs but I am considering switching to an alternative.
Here's an example schema where I'd want to consider speed and ease of access as keypoints:

Relational - One table for users, one table for the cars they own and one table with varying lengths of properties listed for each car. So the cars table would reference the user in the users table, and the properties would reference which car they belong to (all via unique id/key).

Non-Relational - Multiple ways of achieving this, but the most obvious to me would be an object for each user, which I can best describe or return in json, ie :


Let's also assume there's 10000 users and each user has 5000 cars, and each car has 100-1000 props (yes they're very rich :D)
As far as I've read, the latter should be easier to change at any point, be simple to access and also offer similar speed.
Thoughts ?

If you want to enforce any kind of relational constraints, you should use a relational database.

If you don't care about consistency, use a key-value store like CouchDB

If you only care about performance, use redis as a cache layer in front of whatever else you're using

Relational databases aren't slow, and at this point you can extend them with json blob columns in addition to your fixed schema for more flexibility anyway

This post was edited by Klexmoo on Mar 4 2021 05:05pm

i don't think you need to adopt one or the other.

at work, we use a relational database, but we do have json blob columns containing an object where it makes sense. for example, our document table has a json blob full of data captured from that document. if not, either the table would have a ton of columns or we would need more tables for no good reason.

those json blobs/objects can be transposed into columns and/or queried just as easily.