Question

我从回来就是一个RDBMS人。我正试着去三联店。我认为我的“困惑”可以用以下问题的答案解决：

这是怎么回事......

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

......不是三元店？

如果是，那么请评论为什么这个实现（作为RDBMS）效率低等等。

提前致谢!!

Answer 1

在某种程度上，在RDBMS之上实现三重存储是可能的。目前有几种系统可以做到这一点，并取得了不同程度的成功。然而，由于他们的设计通常需要的传递性自联接，它们往往表现不佳。这就是为什么提供由关系数据库（如Oracle）支持的三重商店的严肃供应商已经定制了处理，以帮助提高他们在这些情况下的效率。

根据我的经验，为存储和查询RDF而设计的原生三重存储总是优于在关系系统之上的解决方案。因此，虽然它们非常数据库并且与传统的RDBMS有许多共同点，但它们的实现仍然存在设计选择，使它们更适合回答SPARQL查询。

请帮我'grok'三重商店

1 个答案: