Data Locality Rules

a few rules that made themselves apparent:

Properties must appear in 1 table

The query handler must decide where to look for a property. If it has to look in multiple places, the query gets much more complex:

SELECT ...
FROM Orders,Products,Statements,RdfIds
	  WHERE Orders.

(reference same query with only one source for product name)

This query won't work as certain paths through the disjunction are uncostrined with regard to the list of joined tables.

The major implication is that you can't have some of the foo relations expressed in a database predicate and leave some in the triple store.

Entities must appear in 1 table

Breaking this rule is less catastropic than the Properties must appear in 1 table rule.

Process app-optimized schema queries before the generic triple store queries

Statistically, I believe this will give you the most constrained set with which to enter the more expensive self-joining graph query on the Statements table.

DB Schema

Adapting from

CREATE TABLE RdfIds (
  id int(11) NOT NULL auto_increment,
  type enum('ID','Ref','String','Fake','Gen') NOT NULL default 'ID',
  genId int(10) unsigned NOT NULL default '0',
  uri int(10) unsigned NOT NULL default '0',
  string int(10) unsigned NOT NULL default '0',
  PRIMARY KEY  (id),
  UNIQUE KEY u_uri_genId_string (type,genId,uri,string)
) TYPE=MyISAM;

the question of how to reference app-optimized tables is tricky as the tables selected in a join may not be variables. The use of RdfIds to express entities from arbitrary tables implies this operation. Therefor, the local unifier must handle all junctions in the situations where the name of the constructed node (RdfId for a tableized entity) cannot be made a function of other table names and field values before the Statements query is made.

For example:

((rdf::type ?o foo::bar)
 (OT::Customers.familyName ?o "Walker"))

The query translator would have

Emergent Issues:

Rdfids Field For Each Entity vs. Field With Entity Name.

Entities Have Same Primary Key Name vs. RdfIds Field With Primary Key Name.

Single Field Primary Key vs. Multi-Field Primary Key.

Field per Table, Fixed Key, Single Field Primary Key

+----+-------+-------+-----+--------+-----------+-----------+--------+----------+
| id | type  | genId | uri | string | Addresses | Customers | Orders | Products |
+----+-------+-------+-----+--------+-----------+-----------+--------+----------+
|  2 | Table |     0 |   0 |      0 |      NULL |      NULL | 2185   |     NULL |
+----+-------+-------+-----+--------+-----------+-----------+--------+----------+

Field per Table, Variable Key, Multi-Field Primary Key

+----+-------+-------+-----+--------+-----------+-----------+---------+----------+
| id | type  | genId | uri | string | Addresses | Customers | Orders  | Products |
+----+-------+-------+-----+--------+-----------+-----------+---------+----------+
|  2 | Table |     0 |   0 |      0 |      NULL |      NULL | id=2185 |     NULL |
+----+-------+-------+-----+--------+-----------+-----------+---------+----------+

Table Name Field, Fixed Key, Single Field Primary Key (fully normalized)

+----+-------+-------+-----+--------+-----------+---------+------------+
| id | type  | genId | uri | string | tableName | tablePK | tableRowId |
+----+-------+-------+-----+--------+-----------+---------+------------+
|  2 | Table |     0 |   0 |      0 | Orders    |      id |       2185 |
+----+-------+-------+-----+--------+-----------+---------+------------+

Table Name Field, Variable Key, Multi-Field Primary Key

+----+-------+-------+-----+--------+-----------+------------+
| id | type  | genId | uri | string | tableName | tableRowId |
+----+-------+-------+-----+--------+-----------+------------+
|  2 | Table |     0 |   0 |      0 | Orders    |    id=2185 |
+----+-------+-------+-----+--------+-----------+------------+

The Field With Entity Name option was chosen as join between the RdfIds table name and the table of that name is impossible either way. Field With Entity (table) Name approach has the benefit of a fixed number of fields.