For content, what are the differences between nodes and terms

Question

I am debating whether to use nodes or terms to store a large amount of content in Drupal.

There are a lot of similarities between nodes and terms in Drupal 8/9:

• Both can add any type of field.
• Both can have URL aliases set automatically via Pathauto.
• Both can have customized metatags via Metatag.
• Both can have comments.
• Both can have the displayed customized with Layout Builder, and both can be themed in the same way with Twig templates.
• Both have content types (nodes have "content types", terms have "vocabularies").

They seem very much alike. So what are the differences between terms and nodes?

Answer 1

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 :

1. 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?

2. 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 :

1. get node basic information (nid, vid..) from the entity type base table: node table
2. get node base fields(title,created...) from the node_field_data
3. 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

​

Answer 2

Nodes are content. Terms are for categorization of content, they are not content themselves.

Terms are part of taxonomies. Taxonomy is the science of classification.

The relation between nodes and taxonomy terms is that you attach taxonomy terms to nodes, to categorize the node. So if you have a blog node, you may have topics or tags, that would be attached to the blog node. You can use that to find all blogs of a certain category, or tagged with a given term. You can think of hashtags on common SNS sites as being like taxonomy terms. When you click on the hashtag, you can see all posts with that hashtag. The hashtag essentially categorizes the post.

You have listed some ways in which nodes and terms share technical implementations, such as having revisions. But how they are used is entirely different.

Answer 3

Here are the differences I have identified between terms and nodes so far.

Authoring information + promotion options

• Nodes offer "Authoring information" to change the node author and/or publishing date; taxonomy terms do not. This means that if you want to reference the author of a term, or the publication date, you have to do something like add fields to each vocabulary and roll your own solution, which is a real mess.
• Nodes have a UI option to promote content to the front page and to keep it a sticky at the top of lists. Taxonomy terms don't provide this out-of-the-box, but their display can be customized with Views and they have built-in support for hierarchies, so they don't need sticky at the top of lists.

Hierarchical (tree) structure

• Taxonomy terms are hierarchical within a vocabulary by default. This can be used to provide a menu automatically with modules like Taxonomy Menu or Hierarchical Taxonomy Menu.
• Nodes can be given a hierarchical structure in a menu (the menu contains the hierarchy), but the nodes themselves cannot be ordered in a hierarchy without some kind of custom system relying on entity references.

Revisioning

• Nodes have a revisioning UI and you can easily roll back to previous versions.
• Taxonomy terms have revision tracking enabled by default but there is no UI available yet. This will change someday.

Menu support on the edit page

• Nodes can easily be added to a menu on the edit page.
• To add a term to the menu, you have to create the term first and then manually create a link on the menu you want to add the link to.