Clojurians Log v2

i don't quite understand the purpose of this post. i thought there'd be technical details about how you'd switch over from an existing db to datalevin, but this is mostly about how many existing software that uses EAVs are moving away from them or mutating them for their own purposes

As I have replied there, I don't know what the negative is about. If you want a popularity contest, we all would still be using COBOL. As a technical person, one should be making technical decisions on technical merits, not some survey. It is even more absurd to let an AI to tell you what to use. AI is trained on existing data, which by definition reflects the average of the prevailing knowledge. If that’s what you're looking for, you don't need AI to tell you that. Just go with the flow.

So you don't need a survey to tell you Datalevin should or shouldn't be used in place of other DB. I can tell you right now, it should, because that’s what Datalevin is designed to do: replacing SQL DB.

I think you are missing an important point that I am the first and only person making it, and I quote “With Datalevin, I have demonstrated that a triplestore has some unique advantages compared with row or column based databases. It helps with solving the difficult problem of cardinality estimation, while its shortcomings can be easily mitigated by nested storage of triples. ” from my 2024 blog post: https://yyhh.org/blog/2024/09/competing-for-the-job-with-a-triplestore/

That's the technical point that no survey will tell you, but it is so obvious in hindsight.

SQL DB will not be able to solve the cardinality estimation problem, because it is akin to making something out of void, despite the countless research papers. It is an unfixable fundamental limitation. Triple store’s problems are fixable, as demonstrated in Datalevin, and there are still huge rooms for improvement.

Thanks — and I think my wording caused most of this. "Negative results" meant my search failed, not that Datalevin failed. Those read very differently and I picked the wrong phrase. What I was actually after: are there low-hanging fruits in existing domains that I'm overlooking? Places where domain knowledge is already encoded in an EAV-shaped model, and where Datalevin could be applied without me having to build a whole application first. I went looking for those and didn't find ones I could act on. That's a statement about my search, not about the database.

There is nothing special about EAV, you don't need a domain “suitable for EAV”. Every domain is suitable. So that's the wrong question.

Most of my book is trying to say, any data problem can be casted in the EAV shape, because it is the most atomic shape of any data.