Reusing existing content types for very similar content

Question

Let's say I have n categories of "means of transport" I need to display on my site (aircrafts, cars, bikes...). They share a lot of attributes like "name", "weight", "manufacturer" etc. But each of them also has a small number of distinct attributes that they do not share with others (e.g. only an aircraft has an attribute "wingspan").

I've addressed this myself and seen this issue in related questions here, here and here (and many more) and I do understand that opinions vary as there is (probably) no definite right or wrong answer.

However, I'm still wondering if there exist Drupal-based pros and cons (in terms of performance, maintainability) instead of pure personal preferences for planning your content model one or the other way.

Approach 1: My first thoughts were similar to the following approach, which does not appear to be the optimal use case for the paragraphs module:

• 1 content type "means_of_transport" with a set of basic fields (name, manufacturer, weight...) that are shared by all.
• 1 field that references a taxonomy X with terms "bike", "car", "aircraft"... to tag each piece of content.
• n fields that each reference a different paragraphs type, containing all the fields that are specific to a certain piece of content (e.g. the "wingspan" & "call_sign" compound field for aircrafts)

This results in 1 content type with n paragraphs types. As Hudri and Kevin already pointed out there does not seem to be much benefit in just shifting the complexity from content types to paragraphs types.

Approach 2:

• n content types "bike", "aircraft"... with all the attributes (fields) that are shared between them being reused, so that you don't need to create a new field for "name", "weight" etc. each time, but also each content type having a few unique fields that are specific to it.

Let's say I'll go with approach 2 and n=50 content types and each means of transport only has 1 unique attribute, all the other ones are shared and their fields could be reused. To me that seems very inefficient and often you read one should try to reduce the number of content types when planning your site. But maybe that's the Drupal way to do it and by reusing most of the fields you do not create too much overhead anyway.

Is there any other possible solution to "reuse existing content types with different fields" as also indicated in this answer by Jaypan?

Again, I'm interested in facts that support one or the other approach (and I'm aware they might not exist at all and it comes down to personal taste).

Answer 1

Nodes are a generic entity, with each bundle (content type) being it's own type (ie - a means of transport). This is too generalized. As such, I would say that this is a case for a custom entity, rather than nodes. Your custom entity would be means of transport. You would then create base fields on the entity type for the fields common to each means of transport. You would then create bundles (which for nodes, are known as 'content types') for each separate means of transport (car, plane, bicycle etc) and add means-specific fields to the bundle.

Answer 2

You could use one content-type and as many fields needed to define all the unique features of each transport type.

Obviously, not all the fields will make sense for all type transports at that point.

Then you can use Conditional Fields module to organize availability of each fields based on the entries on the fields as you enter.

From the module description:

Conditional Fields allows you to manage sets of dependencies between fields. When a field is “dependent”, it will only be available for editing and displayed if the state of the “dependee” field matches the right condition. When editing a node (or any other entity type that supports fields, like users and categories), the dependent fields are dynamically modified with the States API. A simple use case would be defining a custom “Article teaser" field that is shown only if a "Has teaser" checkbox is checked, but much more complex options are available.