I have a case where I have a lot of entities that can be stored with Drupal as node (content types) and fields. I had to end up creating 105 content types, 20 taxonomies and in-numerous fields. And the result is that I have right now 1600+ tables in my database. I'm assuming that is not healthy. Please advise.

The other option that I have now is to create entities. I can use entity api module to create a lot of the above content types as separate entities with all properties which would mean that one entity information is stored in one table as opposed to 2 fields for each field (i.e. data and revision). The data in these content types need to be imported but I do not need any CRUD interface for them. Will my database calls be better in terms of performance if I make separate entities instead of content types?

My main objective is to be able to present all the information through views. And I believe that if I have entities, I should be able to display the properties through views. Is that true? I have not tried ECK yet, so I am not sure if creating Entities through interface works clean, so some help in that regard will be very much appreciated.

  • I have a site with loads of content types with specific fields for each and views works fine and there is no noticeable load issue due to the number of tables.
    – dibs
    Feb 26, 2013 at 4:25
  • You have asked two kinds questions here, rather you should have asked them in separate questions, this way you will probably get more answers. Feb 26, 2013 at 8:27
  • thanks @dibs .. in your case do you have more than 1000 tables? I was thinking entity should be the way to go to reduce the load on mysql server.. Feb 27, 2013 at 4:51

1 Answer 1


It depends on your requirement. For example, if you want nodes to be revisioned then go for content types. If you do not want them to revisioned and just using them for storing content then I think entity would be a better option.

Update: 19th June 2016 Thanks to @jon-freed

When it comes to performance-sensitive projects, nodes should really only be used for content, and we should separate as much as possible from nodes. Why? Nodes are revisioned, they fire a lot of hooks, and they have functionality that we likely won't need. Also if we know exactly what fields we should have in our entities, we can create our own custom entities to avoid all those joins of Field API tables.

As far as the choice between ECK and entity api module, it also depends on your requirement. Entity api module provides more control over an entity, for example if you want to create an entity controller for the entity then you should use entity api module. If you just want to create an entity and define some properties then go for ECK. ECK also allows you to created bundles for entities.

Also, you can easily create views for the entities, this site provides great example to work with entities.

Reference: Drupal 7 Entities: What are they, and what are they good for?

Update: (19th June 2016)

It is true that using fields will increase the number of tables, which means more JOINS during database queries. If the purpose is to store data only then you should go for properties. If you want to take advantage of Drupal fields (display the data in cool ways), then you should go for fields, but in this case you have to think about the performance.

We can add fields to nodes and custom entities. Therefore, using nodes will not affect performance. You can always alter properties of an entity using hook_entity_property_info_alter(&$info)

  • I dont think revisions is the only advantage of nodes.. you dont have to write any code if you want to use your content as a node, plus you get a lot of properties and functionalities attached to the node without much ado.. however, I agree with you when you say, go for entities.. Feb 27, 2013 at 4:53
  • Bear in mind you can create revisions for custom entities too.
    – Felix Eve
    Feb 13, 2014 at 11:04
  • 1
    >"Nodes are revisioned". Please correct this. Sure, they can be revisioned, but they don't have to be. >"they fire a lot of hooks". Which of those hooks are bad or unneeded? And is this still true in the Drupal 8 world? >"they have functionality that we likely won't need." Like what?
    – Jon Freed
    Apr 12, 2016 at 4:13
  • @JonFreed answer updated. Let me know if this okay. Jun 19, 2016 at 14:37

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.