Drupal Answers is a question and answer site for Drupal developers and administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In this presentation, slide 13 says (emphasis mine):

The relationships between Entities- the ways entities can interact either each other - define our Drupal application

nodes can have comments
users create nodes
taxonomy terms are attached to nodes

these relationships are implicit - perhaps they should be explicit?

What does the last sentence mean? In Drupal, what makes entity relationships implicit rather than explicit?

share|improve this question
up vote 2 down vote accepted

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`)

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`)

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.

share|improve this answer
Very clear. Thanks for clarifying my understanding and for editing my question earlier. Don't have enough rep to upvote your answer yet (but will up it when I do!) – Andrew G. Aug 21 '12 at 23:17
I up-voted for you :) – iconoclast Aug 24 '12 at 17:54

As it is now, the relationship between (for example) a node, and the user who created it is established from the $node->uid property. It is implicit because it is a relationship that is automatically created from Drupal through a custom property. For Drupal, every node has an author, and every node has zero, or more comments; every comment is associated to a node (and not other entities), and every comment has an author.

This is different from the case where the $node object had a property containing a list of related entities, such as $node->relatedEntities. The user object for the user who created the node would be contained (for example) in $node->relatedEntities['author'], and the comments for the node would be contained (for example) in $node->relatedEntities['comments']. In this case, there would be one or more database tables that contain all the values for those relationships, such as in the following table.

Relationship  | Main entity ID | Main Entity type | Related entity ID | Related entity type
author        | 1              | user             | 345               | node
author        | 1              | user             | 2                 | comment
author        | 1              | user             | 243               | node
comment       | 234            | comment          | 345               | node
author        | 1              | user             | 234               | comment

If this were the way the relationship between nodes and author were stored, the node table would not define the uid field containing the user ID for the node's author. In the same way, the comment table would not define the uid, and the nid fields.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.