Best way to set up data architecture

Question

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?

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.