Please help me 'grok' triplestores

Question

I'm an RDBMS person from way back. I'm trying to grok triplestore. I think my "confusion" may be addressed with the answer to the following question:

How is this...

Table (Subjects):   
ID  Subject     Details
1   Barney      …
2   Fred        …        
3   Picture     …
4   …

Table2 (Predicates):
ID  Predicate       Details
1   friendOf        …
2   marriedTo       …
3   hasTimeStamp    …
4   hasGeoCoord     …
5   hasEventName    …
6   belongsTo       …
7   containsPerson  …
8   …

Table3 (Objects) - These may be Subjects as well:
ID  Object                  SubjectID   Details
1   Fred                    2           …
2   Wilma                   NULL        …
3   January 1, 2010 1530    NULL        …
4   46°12′N                 NULL        …
5   6°09′E                  NULL        …
6   Wedding                 NULL        …
7   Ski Trip                NULL        …
8   Barney                  1           …
9   …

Table4 (Triplestores)
ID  SubjectID   PredicateID ObjectID    Details
1   1           1           2           …
2   2           2           3           …
3   3           3           3           …
4   3           4           4           …
5   3           4           5           …       
6   3           5           6           …
7   3           5           7           …
8   3           7           8           …
9   3           7           2           …
10  3           7           1           …
11  …

So #9 in Tripstore is: Picture containsPerson Fred

...Not a triplestore?

If it is then please comment on why this implementation (as an RDBMS) is inefficient etc.

Thanks in advance!!

Answer 1

It's possible, and easy to some degree, to implement a triple store on top of an RDBMS. There are several systems currently available that do this with varying degrees of success. However, they tend not perform all that well due to transitive self joins their design usually requires. This is why serious vendors who are providing a triple store backed by a relational database, such as Oracle, have customized handling to help improve their efficiency in these situations.

In my experience, native triple stores, those designed for the purpose of storing and querying RDF, always outperform solutions shoehorned on top of a relational system. So while they're very much databases and have a lot in common with a traditional RDBMS, there are still design choices in their implementation that makes them better suited for answering SPARQL queries.