[okusername]

Both of you are missing the point. Once you normalize, car color would be an attribute on the car table, and to map those you need many-to-many lookup tables. It can be done obviously, but it's more effort to do, maintain and update. Depending on your requirements, graph db like features can provide an easier abstraction.

[taeric]

This feels like a straw man. Don't normalize if it causes pain.

Similarly, don't expect that a single data model will suffice for all needs in an application. Expect to have to maintain anything that is useful.

[okusername]

Obviously, if you put all data into one table, it's not a complex query. (But then you also just reinvented document databases with its own set of problems.)

Even having them in several tables is not rocket science, OP was just trying to give an easy example of types of queries that are easier with datomic than with sql.

[taeric]

My point is that data has to be maintained in whatever forms you are keeping it in. Often with different requirements on why it is there.

Yes, this is a large part of why we use databases. They will do most of this heavy lifting. However, I don't think it changes the game. If you want some access to be easy or quick, you have to maintain the data in that format.

[okusername]

No, you're completely wrong. Graph databases, document databases, K/V stores and so on have completely different models, guarantees and performance characteristics than relational databases.

[taeric]

That is restating my point. Different data stores have different characteristics. Identify which ones you care about and make the tradeoffs required. They all require effort. And it is not uncommon to want your data available in different ways at different times.