Entity vs. Node

I was just talking with a friend about this earlier tonight. Unfortunately, I'm not the best person to answer this - but I can give you thoughts to keep you going until someone else jumps in. 

1) In Drupal 7 I believe that you could create a custom entity through the UI with the Entity Construction Kit module https://www.drupal.org/project/eck/. To my knowledge (and I looked), this module does not exist for Backdrop CMS. 

2) I believe that the only way to create custom entities for Backdrop CMS would be with custom code. Personally, I would try googling "Drupal 7 Create Custom Entity" - I think you will find lots of documentation. Much of it MIGHT be useful, but I'm not sure. If you are in a rush, you could give this a try. Otherwise, wait for someone with more info. 

3) My last thought is that you MIGHT be able to accomplish what you are looking for with taxonomy. Taxonomy terms are fieldable and you can reference them. Based upon your description, I think that is how I would likely handle your use case, but I may be missing something. Create a vocabulary for "mode of operation" and add your custom fields. 

My understanding is that an entity is a subset of a node. In other words, an entity consists of fields stored in the DB, without all of the additional overhead (and associated DB fields) of a node for its display, translation, etc. Please correct me if I am misled or incorrect.

You are close on this one, but I understand it to be the opposite. Nodes are a subset of entities. Nodes are entities that come with extra overhead. Entities are the most basic form of content. Nodes, Taxonomy Terms, Files are all different types of entities. You are looking for an entity type that is different/simpler than a node and if I'm correct, taxonony terms might work for you. 

As the previous people have mentioned, "Entities" in Backdrop and Drupal are not a subset of Nodes, back rather the other way around: Nodes are Entities, as well as other data structures in Backdrop such as Taxonomy Terms, Files, Users, etc. 

I wanted to mention a module I recently created called Basic Entity Plus Example  that provides a ready-made example of a custom entity.  The entity provided there is a "cousin" of Nodes, but it gives you the flexibility to customize it without messing up the original Node architecture. A few notes about the entity provided in the example:

• It's "fieldable", meaning that you can add Backdrop fields to it through the UI
• It's "bundeable", meaning that you can create, through the UI, new "types" of that entity, the same way you create new "content types" of nodes. Each of those types can have different fields
• It's accessible through Views, meaning you can create views to display all the content entered in those entities, and you can create relationships to other entities

One more word about your project: whether you end up using custom entities or different content types (nodes), you will need to use a field that allows you to create references among entities/nodes. I recommend Entity Reference , which creates a new field type you can add to your nodes or to your custom entities.

Last word: custom entities created with Entity Plus and Entity UI like the one example I created are NOT "lighter" than Nodes. They are very similar in many ways: they use at least two DB tables: one for storing the entity content, and one for defining different entity bundles. In addition, every field you create (whether it's nodes or entities) create one or two additional tables to store the content of the fields, and sometimes the revision (old content).

I've used custom entities for a long time, and can help answer any quick question you may have. Try using Backdrop's Zulip channel for quick answers. 

Great responses, but to answer one of your questions, proably the main question, how to create an Entity, it can actually be quite simple, in fact. You need an Entity Class file, and you need to implement hook_entity_info() and hook_autoload_info() at minimum. 

For the hook_entity_info() lots of examples available but the minimum code required:

function entity_test_entity_info() {
  $return = array(
    'entity_test' => array(
      'label' => t('Test entity'),
      'entity class' => 'TestEntity',
      'controller class' => 'EntityDatabaseStorageController',
      'base table' => 'entity_test',
      'fieldable' => TRUE,
      'entity keys' => array(
        'id' => 'id',
      ),
    ),
  );
  return $return;
}

For your entity class, the minimum code is:

class TestEntity extends Entity {
  public $id;

  /**
   * Implements EntityInterface::id().
   */
  public function id() {
    return $this->id;
  }

  /**
   * Implements EntityInterface::entityType().
   */
  public function entityType() {
    return 'entity_test';
  }

  /**
   * Implements EntityInterface::label().
   */
  public function label() {
    return 'label';
  }

  /**
   * Implements EntityInterface::uri().
   */
  public function uri() {
    return array(
      'path' => 'test/' . $this->id,
    );
  }

}

And autoload to tell Backdrop where your Entity class lives:
 

function entity_test_autoload_info() {
  return array(
    'TestEntity' => 'entity_test.entity.inc',
  );
}

You'd need a db table called test_entity or whatever you define in 'base table' in entity_info, And thats it, you have an Entity. 

If you did $first_entity = entity_create('test_entity; array('id' => 1)); then $first_entity->save() it should work fine and save to your db. All the load, etc functions should work.

But of course this is the minimum.

@ericfoy - I hope that someone more confident in this subject matters chimes in here, but based upon my experience, I think your understanding is pretty accurate. Most of us don't talk much about 'entities' and 'bundles' in Backdrop, but my understanding is that in theory these terms are still accurate and work the same as they do in Drupal. This chart for Drupal 8 seems to be saying exactly what you are saying and I would assume this is true for backdrop.
https://www.drupal.org/docs/drupal-apis/entity-api/bundles

I think that you MIGHT be overly worried about the overhead of nodes, but given your situation, I MIGHT also be going the same direction that you are anyway, just because it feels cleaner. 

I've often went into a project thinking I MIGHT need a new custom entity, but it never seems to come to that. I usually find a way around it. Sometimes with a vocabulary or another entity provided by a contrib module (in Drupal Groups are an example). 

I will not speak to the issue of "Field Collections" - because I have not looked at them in a long time. 

Again - I really do hope that someone more conversant in "Entities" and "Bundles" chimes in here and offers their opinion (and corrects any mistakes I might be making). 

Is my concern for the overhead of nodes (content types) at all valid, or should I just relax a little, and make everything a node and not worry about it?

I don't know the detailed architecture of entities and nodes, and I'm not able to evaluate the technical overhead of using nodes about using custom entities. From a practical perspective, using nodes could also mean less overhead because it's much less work to build the entities itself (and some of their features in case you need them).

By the way, are you aware of the setting "Hide path display" in the "Display settings" tab of the node configuration form? In my opinion it's a great start for custom-entity-like node types.

@ericfoy, you are not alone in the struggle to understand the lingo of entities in Drupal (and Backdrop). It's confusing, and unfortunately sometimes the UI/end user terms do not coincide with the developer/programmer ones to describe the same thing (e.g. "Content" and "Content type" are only used by the end user). To add to the confusion, "type" and "bundle" are sometimes use interchangeably, but they mean different things (a "content type" for an end user is a "node bundle" for a developer).   

I suggest this article, which explains the terminology pretty well, as well as some the other linked resources at the bottom of that article.

The entity_example module provides a very basic example of a custom entity, but it's a great starting point to develop your own.

You are correct: the entity defined in the entity_example module you mentioned provides only ONE fixed bundle (named first_example_bundle), and the example does not provide a way to create other bundles through the UI. In order to create other bundles of that entity type you need to modify the code, specifically under the key 'bundles' of the function entity_example_entity_info(). 

If you want an example of a custom entity that uses the UI access to create new bundles I suggest the Basic Entity Plus Example I mentioned in my comment last week. It uses the module Entity UI to provide the bundle creation UI. 

Regarding the location of the menu links of entity_example: keep in mind that the links are not "fixed," and are actually defined  in entity_example_menu() and also under the 'admin' key under 'bundles' in entity_example_entity_info() (this 'admin' key tells the Field API where to place the field management admin UI).

As for using nodes exclusively to tackle your project - it IS possible! I wouldn't worry too much about overhead. In the end the number of tables end up being similar with nodes or custom entities (BTW, each new field you add to a node bundle usually creates two additional tables - this is also true for custom entities. Unless you reuse fields in different bundles). 

When I first starting working with Drupal 7 I needed, like you, 6 or 7 "content types" with different fields, and I worked exclusively with nodes and with the module Entity Reference to create relationships between those nodes. It was OK - there were some drawbacks to it, but you can make it work. Later I started using custom entities, mostly because you could customize their classes more easily and you could split all the admin interface away from the Content and Content Type areas of the admin ui.