A lot of the early academic RDF graph databases used this approach. However, performance was no where near to what is
required.
This let to for the SPARQL/RDF graph databases to now a whole set of independently developed stores. Some on top of existing solutions e.g. Oracle semnet, Virtuoso and DB2 sparql. More on their own solid foundations.
You could test out 3 or 4 different SPARQL solutions in the time that it would take you to develop something graph like on your own.
In short you can build something yourself. But don't expect that it will be better than something build and supported by someone else.
So investigate the competition: BlazeGraph, Virtuoso, StarDog, Oracle 12c EE/semnet, DB9, Dydra before deciding to build your own. Building your own because its fun to do is great, but unless it pays your bills not a good idea for production environment.
PS. The edge table (EAV) is the major problem, it leads to a lot of self joins and difficult exercises for the query planner.
You can improve a lot on this if you can put "different" edges into different tables or partitions.
Triple stores with support for JSON-LD framing such as Dydra can also make it easier to have a front-end on top of your DB without extensive middle layer code.
A store like StarDog and BlazeGraph on the other hand gives you a lot of flexibility by both supporting SPARQL and TinkerPop. (both cluster and scale out, although BlazeGraph has GPL option. StarDog is only Commercial)
Ah ok, so in RDF terms each predicate gets its own table, which makes sense. Then you have a subject foreign key relation ship and a object foreign key relation ship to the node tables.
That would be better than one big table in performance, which was a major problem in the RDF on SQL databases.
Of course those accepted any graph, if one constrains the number of possible predicates/relations then this solution could more efficient.
Comments
A lot of the early academic RDF graph databases used this approach. However, performance was no where near to what is required. This let to for the SPARQL/RDF graph databases to now a whole set of independently developed stores. Some on top of existing solutions e.g. Oracle semnet, Virtuoso and DB2 sparql. More on their own solid foundations.
You could test out 3 or 4 different SPARQL solutions in the time that it would take you to develop something graph like on your own.
On the other hand, cutting edge approaches, actually take a graph representation of data and lay it out in a relational manner. http://ercim-news.ercim.eu/en96/special/monetdb-rdf-discover... giving the best of both worlds.
In short you can build something yourself. But don't expect that it will be better than something build and supported by someone else.
So investigate the competition: BlazeGraph, Virtuoso, StarDog, Oracle 12c EE/semnet, DB9, Dydra before deciding to build your own. Building your own because its fun to do is great, but unless it pays your bills not a good idea for production environment.
PS. The edge table (EAV) is the major problem, it leads to a lot of self joins and difficult exercises for the query planner.
You can improve a lot on this if you can put "different" edges into different tables or partitions.
Triple stores with support for JSON-LD framing such as Dydra can also make it easier to have a front-end on top of your DB without extensive middle layer code.
A store like StarDog and BlazeGraph on the other hand gives you a lot of flexibility by both supporting SPARQL and TinkerPop. (both cluster and scale out, although BlazeGraph has GPL option. StarDog is only Commercial)
edge is not stored as IAV the table hierarchy is:
which is strange since an edge is already a M2M.
Thanks for the monetdb link.
Ah ok, so in RDF terms each predicate gets its own table, which makes sense. Then you have a subject foreign key relation ship and a object foreign key relation ship to the node tables.
That would be better than one big table in performance, which was a major problem in the RDF on SQL databases.
Of course those accepted any graph, if one constrains the number of possible predicates/relations then this solution could more efficient.