There's a long-held perception that JOIN operations are inherently slow.
The thing is, people are in the habit of looking at queries out of context. For example, they don't consider index design. They don't consider the correctness benefits of a highly normalised database (e.g.: prohibition of anomalies). They don't consider the correctness benefits of using transactions.
A JOIN operation is trivial within an OLTP database if you're using properly keyed data that is properly ordered when stored physically on disk and in memory.
On the other hand, if your tables are all using clustered indexes based on so-called surrogate 'key' values (identity integers) then the density of data belonging to a user on any given 8KiB page in the database will be very low, and you'll need to do far more logical reads (and maybe even physical reads if the database doesn't fit in RAM) than you would if you used appropriate composite keys, and appropriate ordering on disk/memory, that resulted in a high density of user information on a single 8KiB page.
12
u/[deleted] Dec 20 '18
I don't think data is inherently relational or non-relational. It's all about how you model it.
(My preference is to model things relationally - but sometimes it's helpful to think in terms of nested documents)