I have a system where (to start) I have three types of data I need to store. I'm familiar with relational databases so I'm going to describe it in those terms. The Author table just has a couple columns like a primary key, and a few text fields (it's info about an author). Location has a similar structure to Author, but it's for different data (info about locations). Article is basically what links the two together. It has some regular text data, but also has foreign keys to both Author and Location (it's an Article written by Author about Location).

I've played with two ideas for how to represent this in Drupal. First with the Field API creating content types. The main problem here is that I'm not sure how to set it up so that Article has the proper relations to Author and Location.

The second approach I'm considering is using the Entity API module, but I'm not really very familiar with the module. However, I am very comfortable using hook_schema() to set up the tables and relationships. From there, I'm not sure if Entity API has much useful in the way of making the data manageable like a content type or if I'd have to write that all by hand to begin with.

Am I looking at this all wrong? What is the drupal way?

1 Answer 1


There are quite a few possibilities to deal with this.

To get an overview:

  • The advantage of custom entities is that they don't come with all the overhead that nodes have. They're especially well suited for storing and managing completely custom data that you might not even want to display and you have full control over them (their data structure, workflows, UI). The commerce project for example defines own entities for orders, products, line items and so on.

  • Nodes are still the main content pieces. They provide various features that you don't yet get for free with custom entities, like revisioning and comments. Various additional modules focus on nodes. In short, you get a ton of features, but have to live with the overhead that comes with them. Every additional data structure you need is a field, living in it's own table, and so on.

  • Entity API provides a lot of features for custom entities, for example CRUD and allows you to easily integrate with various important tools like Views and Rules. It's definitely worth to rely on it, see http://www.trellon.com/content/blog/creating-own-entities-entity-api for a nice introduction.

  • To connect entities (Hint: nodes are entities as well), you can for example use Entity reference (simple, directed relationship) or Relation (flexible, unidirectional relation between entities which is an fieldable entity on it's own).

Some specific tips based on that:

  • Article sounds like a perfect use case to use nodes/a content type to me. People need an UI to create them, you might need revisions, maybe comments, they need to be displayed, probably want nice aliases (Pathauto) for them and so on.

  • Author; Here you have a bunch of options. Nodes have an author by default, the user that created them. Users can have fields as well and can have a public profile, so your authors could actually be users. Especially if your authors are going to be the uses which will create the articles on your site themself. If not, then this might not be a perfect match because changing the author of a node requires administrative permissions. If not, you could either use another content type if you think that makes sense or create a custom entity.

  • Location: The traditional answer are certainly taxonomies. They're still a good match to categorize content, provide a number of possibly useful features out of the box, like hierarchy (so you could do do Country > State > City), auto-create new locations from a autocomplete widget and a list of nodes attached to them. And, they're fieldable entities too (surprise!), so you can store additional information for them as well.

So, to me it sounds like the default entities provided by Drupal core are a pretty good match for your data.

  • I think that might be a bit too simplistic for Location. But perhaps I don't know enough about taxonomies. Can you still have meta-data associated with a specific taxonomy? Things like images, descriptions, etc.
    – gregghz
    Jun 1, 2012 at 19:05
  • The key is that all three need to be independent of the others in addition to the specified relationships. With that, simple content types might be the best solution given things like Entity reference (that seems perfect actually).
    – gregghz
    Jun 1, 2012 at 19:09
  • Yes, you can add fields (including images) to taxonomy terms, and a description actually exists by default. But you could of course also create a Location entity type and connect those using an entity reference.
    – Berdir
    Jun 1, 2012 at 19:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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