1 -node VS taxonomy_terms
both node and taxonomy_terms (terms), are a content entity types so they both used to store content , but form a semantic point of view :
node ( Content ): are used to store a content because their base fields and related entities are intended for that purpose ex :
- created: when the content has been created?
- changed: when the content has been changed?
- sticky: do you want o make this node stick to the top of others?
- Authored by: who writes this content?
- Authored on: when the content has been created?
taxonomy_terms ( Classification ): is used to store classifications (grouping content that shares same properties in the same group) because their base fields intended for that purpose ex :
- name: the category group name that will be used to group a set of nodes or other entities.
URL alias: a link to a page that will contain all the nodes that belong to this category.
also, we can use the taxonomy Hierarchical (tree) structure for a nested classifications
SO NODE MUST BE USED TO STORE CONTENT AND TAXONOMY TERMS TO STORE CAISIFICATIONS.
2- Performance problem with node
if you will save a large amount of content as a node you'll have a big performance issue, let's say you have a web service that consumes a thousand of tweets and save them as nodes this will cause a big performance problem because :
when we want to retrieve a node tweet a long database query journey will be traveled :
- get node basic information (nid, vid..) from the entity type base table: node table
- get node base fields(title,created...) from the node_field_data
- get each field from node__field_$fieldName , let's say we have 10
fields in each field are in a separate table ( 10 tables)
also, another performance problem since any site will have more than 1 node bundle (article, page, news) beside the one that you will add ex (tweet) each SQL query executed against the DB to read data will loop through all these bundle instances (article, page, news) before getting your tweets.
3- Custom entity type
the best solution if you have a large amount of content :
Creating a bundle-less entity type for fast data retrieving without losing the node editing power because you can keep this property:
- content will be translatable.
- content will be revisionable.
- content can be integrated with the view.
- they can be administrated from BO just like a node.
note: the fast way to generate a custom entity type with Drupal console, using: generate:entity:content then set Do you want this (content) entity to have bundles? (yes/no) [no]: >no