- From: Simon Spero <sesuncedu@gmail.com>
- Date: Tue, 19 Apr 2016 12:36:29 -0400
- To: Pete Rivett <pete.rivett@adaptive.com>
- Cc: semantic-web@w3.org, Alessandro Seganti <a.seganti@cognitum.eu>
Received on Tuesday, 19 April 2016 16:36:57 UTC
On Apr 19, 2016 9:07 AM, "Pete Rivett" <pete.rivett@adaptive.com> wrote: > You should be aware that, if you’re trying to represent real world databases, the situation can get complex since a Key may consist of many Columns. And the same Column may be part of many Foreign Keys and also part of the Primary Key. Thanks to the wonders of RDF, representing compound/composite keys isn't that much harder than handling simple keys. Or to put it another way, handling simple keys isn't much easier :) In both cases, a link between two tables needs to be represented as an instance, because it needs to have properties asserted about it (lo - a graph database :) For simple keys one can use a pair of single valued properties to store the columns to join on. For compound (or composite) keys you can extend this by e.g. representing the compound keys as instances in themselves; keeping a list of pairs of columns (or keeping two lists of columns); or having a multivalued property where each value is a pair of columns. The performance costs of any of these approaches is unlikely to be significant for sane collections of RDBMS schemata. Fortunately we have ORM tools to avoid this. Since rdf lists involve cdr chasing, this can be a performance drain depending on the particular triple store implementation. Using a multivalued property may be faster. Simon
Received on Tuesday, 19 April 2016 16:36:57 UTC