Only the original author knows what he meant by this, as the distinction between implicit and explicit does not have any special technical meaning within the context of Drupal that differs from the normal distinction made in plain English. Nonetheless, here are my thoughts.
The relationships are implicit because there is nothing in the database to define them and give them meaning.
For example, take nodes and users. The {node}
table has a uid
column. What does this mean?
It is implied in Drupal that this is the author. But, it could really be anything: author, owner, sponsor, etc.
In some database designs, tables will never have relationships (ie, foreign keys) to other data
tables directly (I forget which normal form this is).
To do this in Drupal, you would alter the {node}
and delete the uid
column. Then
make a {node_x_users}
table that looked something like
CREATE TABLE `node_x_users` (
`xid` int(10) unsigned NOT NULL default '0',
`nid` int(10) unsigned NOT NULL default '0',
`uid` int(10) unsigned NOT NULL default '0',
`rid` int(10) unsigned NOT NULL default '0',
PRIMARY KEY (`xid`),
KEY `nid` (`nid`),
KEY `uid` (`uid`),
KEY `rid` (`rid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
The actual relationships, via (foreign keys to other tables) would be stored in this table and not in {node}
or {users}
. You would also make a table like
CREATE TABLE `relationship_labels` (
`rid` int(10) unsigned NOT NULL default '0' COMMENT,
`type` varchar(128) NOT NULL default '',
PRIMARY KEY (`rid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
This would store a text version of what the relation type is so you could explicitly define them.
So, when you make a node, you insert the node into {node}
, get the $nid
(which is the PK of the table), then insert the relationship into the cross table, {node_x_users}
along with the $uid
and the key representing the type of relationship. When you render a node, you also JOIN on the {relationship_labels}
to get the "Authored by", "Edited by", etc text.
In the code you end up with more JOINs (but they are all on simple, indexed types), but you also gain some other advantages, the biggest benefit is a very flexible data model.
Personally, I see this as one of the biggest problems with the current Drupal architecture.
An example of a system that does relationships like this is CollectiveAccess.