5

I am working on a module where I need to save thousands or I guess millions of data (product'data from various e-commerce sites). So I am not sure of saving that data in a custom table by using custom entity or should I save that data in nodes?

As for searching, a user can use elastic or search_api_solr and use views for displaying the data, so is it better to use custom row or nodes to save that much of data?

Improve this question
1
  • 2
    There is no difference between “node” and “custom entity” especially if you extend it from ContentEntityBase. Node is a content entity shipped with core providing content publishing on top of it, with various modules integrating with it (and hooks, etc). You can have a million nodes, you can have a million custom entities, the result is the same. It’s all in how you want to manage and develop it.
    – Kevin
    Jun 10, 2018 at 16:06

2 Answers 2

Reset to default
13

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.

Improve this answer
1
  • Also, node_access adds more joins on list queries. No other entities have this by default, even though the possibility exists to add it in contrib.
    – FGM
    Mar 13, 2019 at 10:00
2

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.

Improve this answer

Your Answer

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

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