Should I use an entity reference for nodes or taxonomy terms?

I'm dealing with a plant content type that currently contains a paragraph field. The paragraph contains an entity reference to Common name and an Origin text field (with the setting to create if it doesn't already exist). My reason is that common names can apply to numerous plants.

Before I add data, I'm wondering whether taxonomy terms are better for common names. Do nodes take up less memory than taxonomy term? I don't need more fields than the body field that exists on both.

I don't need any hierarchy. I need a simple way to create, reference, and view pages for that common name, and show any related scientific name.

Which entity to use in the reference field depends on what features you are going to need or implement. The main purpose of taxonomy terms is filtering a list of entities basing on the taxonomy terms they use.

Taxonomy terms are still the lighter entity to use in entity reference fields. The differences between taxonomy terms and nodes are the following.

• Nodes store a reference to the user who created them

  To that user (the node owner) are given permissions other users could not have, for example being able to update the node the owner created (as Drupal implements the edit own content and edit any content permissions). It can also be used to filter the entities shown to a user, or the entities a user can select.

• Nodes don't have a weight or a parent node

  Taxonomy terms have a weight and a parent taxonomy term (used for hierarchies).

• Nodes allow to restore a previous revision

  The user interface to restore a previous revision of a taxonomy term is still not implemented. [PP-1] Add revision UI for taxonomy terms would fix this, but it's now postponed since 4 years ago.

• There are modules that add features associated to nodes, but not to taxonomy terms

  For example, the Statistics module logs content statistics, but not statistics about taxonomy terms; the History module records which user has read which content, but it doesn't do the same for the taxonomy pages (the pages showing a list of entities using a taxonomy term). There are other modules that could require you use nodes instead of taxonomy terms.

It's unclear whether you are talking about "memory" in the sense of RAM/performance or storage.

As for performance, taxonomy and content are both entities, so underneath the performance will be similar. Obviously if you really care about performance you need to do benchmarking, but since you said your needs are simple, I would just use taxonomy because it is designed for sharing common info among nodes.

For example, with the Tags taxonomy vocabulary that comes with Drupal core, you can have thousands of tags on cheap shared hosting and you are unlikely to have any performance issues due to the taxonomy.

As for storage, storing taxonomy takes up slightly more room than adding a Common name field to the content and putting all the data there. It takes up more room because you have to create entities, which have an entity ID and so on. However, this is generally negligible and not something to worry about-- creating a field instead of taxonomy will make it much harder to make your view of common names and to add additional info about them.