[hunterpayne]

Performance, far better performance. Same reason you ever use SQL. Prolog can do the same thing for very specific problems.

PS Prolog is a Horn clause solver. You characterizing it as a query language for a graph database, well it doesn't put you in the best light. It makes it seem like you don't understand important foundational CS math concepts.

[scotty79]

I have no idea why are you dissing query languages. Software that makes those work is immensely complex and draws on a ton of CS math concepts and practical insights. But maybe you don't understand that.

I'm using SQL to do SQL things. And I'm sure when I somehow encounter the 1% of problems that prolog is the right fit for I'd be delighted to use it. However doing general algorithms in Prolog is as misguided as in SQL.

[hunterpayne]

> I have no idea why are you dissing query languages.

I'm not. I'm pointing out that saying a Horn clause interpreter is a graph query language indicates a fundamental misunderstanding on your part. Prolog handles anything you want to say in formal logic very well (at the cost of not doing anything else well).

SQL on the other handle uses a completely different mathematical framework (relational algebra and set theory). This allows really effective optimization and query planning on top of a DB kernel.

A graph DB query language on the other hand should be based upon graph theory. Which is another completely different mathematical model. I haven't been impressed by the work in this area. I find these languages are too often dialects of SQL instead of a completely different thing based upon the correct mathematical model.

PS I used to write DBs. Discretion is the better part of valor here.