Hacker News Reader

Comment by daneel_w | Hacker News Reader

This was quite the lopsided comparison - a document store just doesn't get fair competition in a relational setting. Additionally, both the SQL and the MongoDB queries appear unnecessarily complicated (or inefficient) for the examples they illustrate.

View on HN

Is this actually an objective truth? "relational" just refers to the relation within the table, it's less about having a database system with good inter-table relationship handling. It happens to be that a lot of the things we think about as relational are OLTP and have good fkeys, etc.

Is there any real reason why a document store can't have good joins between collections? If you index the lookup keys, I don't understand what about the underlying document model would make joining impossible to optimize as well as a relational model.

I don't think most document stores enforce foreign key relationships (and hence consistency) like RDBMS do, so in practice that would make joins difficult.

Is joining on an fkey any more performant than without it assuming the same indexing is applied?

When you say difficult do you mean from a developer ergonomics standpoint (knowing there's data integrity), or from a database optimizability standpoint?

The former. You have a guarantee of consistency, whereas otherwise you must adjust for this in your application code. Database performance wise I agree they are equivalent.

This does feel like an article that would have made more sense in 2013 or so, back when the habit of mistaking a document store for a database was much more widespread.

Here is the code for the queries: https://gitlab.com/ahachete/pgmongojoins/-/tree/master/post-... Feel free to send a MR improving it.

Reply on news.ycombinator.com