Should I create fielded content types (with 1000+ tables) OR create custom entities with properties instead of fields (way less tables)?

Question

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.

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)