Drupal - Storing data as entity or node?

I actually disagree with the comment from @Kevin, using or not using nodes can make a huge performance difference, for multiple reasons.

Yes, node is a pretty standard content entity, but..

  • It is revisionable
  • It is translatable
  • It has a bunch of standard base fields like promote, sticky that are likely not relevant for your use case
  • Any data that actually is relevant needs to be stored in configurable fields, which results in additional tables.

So if you need 20 additional fields to store stuff, you end up with 4 base tables and 40 additional tables, so 44 tables in total.

If you don't need revisions and translations and assuming you only have single-value fields, you can do that with a single table instead with a custom entity type and base fields. If you need revisions then it's 2. And each multi-value field does require 2 additional tables but usually there are not that many of those.

With millions of records, it's definitely worth thinking about if creating a custom entity type is worth it and sounds like for that case, the answer is probably yes.

It's worth pointing out that there's still a decent amount of modules (even in core), that currently only work with nodes, e.g. book or diff. So make sure that you don't need any of that or be prepared to re-implement that functionality.


It depends. As Kevin pointed out, there are not much difference as "entities". However: using a custom entity CAN be a big advantage in some cases.

Since nodes are being used in the most cases too many contrib and core modules can integrate with it, which can lead to unnecessary overhead.

When going for custom entity maybe you have to do some initial extra work for it, but then it is in your hands: it's much easier to make custom changes for it. Also can make your code easier to read.

So final conclusion: If you use already a couple of node bundles and your new type will need a special highlight I would go for a custom content entity.

Tags:

Entities

8