This project has moved. For the latest updates, please go here.

EF + B* possible advantages vs other triple stores

Apr 13, 2014 at 10:04 AM

I was thinking why would people use B* db instead of other triple stores for a project and what could help in this direction.
The reality is that there are a lot of triple stores each having at least a basic/limited free option. Also many of them are used in production for years and have teams working full time to solve various issues, so this is hard to compete on.

Implementing a cluster for B* (like suggested in other thread )would be a plus but given the development effort I'm not sure it's worth it at this time.
What I mean is that cluster makes no sense before a single instance can support 100M triples(other stores go to 1B) with a good optimizer and a stable API, and maybe a proven production application that works with it.

So the important advantages of B* are license(price), EF api (+optimistic concurency bonus), embeded support, C# code.
B* EF api is an advantage while it doesn't work well with other stores and there are no other Obj-Rdf-Mappers api's in .net. If either of this are fixed most of the advantage is gone.

What I would also consider is integration with SqlServer and graph functions.
In general an application would have at least part of data in relational format (users,roles, etc)
and some in graph format (in triples store or graph db), so the app db is a hybrid.
To solve this problem in .NET world a nice idea is to integrate SQL Server with another db, using clr functions, like suggested here for Neo4j.
So if B* would have a good integration with SqlServer and graph functions(shortest path, etc) this would mean a great advantage for SqlServer users...most .net world uses sql server anyway.
Apr 14, 2014 at 9:16 AM
Yes there are other triple stores with longer history but they don't meet my requirements. Firstly they are mainly written in Java and require me to run a Java VM. Secondly none of them are properly embeddable and thirdly few of them give me full access to the source code. So I think B* still has a place even if the commercial tools implement the features that B* has. Anyway "competing" is not something that interests me - being functional and fulfilling a task is all that I really care about. B* is relatively new, performance enhancements, query optimizations, sizing and so one will come with time.

SQL Server is not something I am prepared to go for. I have written alot of code with SQL Server and B* came about because of the pain of using SQL Server to do non-relational stuff. DotNetRDF used to have a SQL mapping but Rob took it out, I think for much the same reason.