How to decide to create a content type or two if there are both common and uncommon fields? I have a content type that has about 80 fields.
It has a select list field at top and there are two options: Yes or No.
If Yes is selected all the 80 fields are used and if the No is selected, the last 30 fields are not used. For both two options, 50 fields are common.
I wonder, if I should go for creating two content types for this structure, or if continuing  with &quot;one&quot; (only) is better. If I continue with this &quot;one&quot; content type, 30 fields will be empty for the &quot;No&quot; options and can it be a &quot;bad&quot; thing for the database (waste of space etc.)?
(If I continue with one content type I will use some modules such as Conditional Fields etc).
Is there anybody faced with a similar situation and is there a &quot;better&quot; way?
(Additional information: this content type is used for an academic resource. If the resource is in English I will only fill the 50 fields. If the resource is in another language I will fill the 50 fields and also fill the other 30 fields.)
I would use only 1 content type, and use the Conditional Fields module to hide those 30 extra fields for your select list field with value No.

This excerpt from this module's project page seems to perfectly fit as a possible solution for this approach:


  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.
  
  You can, for example, define a custom “Article teaser" field that is shown only if a "Has teaser" checkbox is checked.


Possible alternative

True, you might also go for 2 content types instead. But in that case you're using an approach as described in the (illuminating, I think) article "Relativity model for Drupal". For more details on that, and the typical modules involved in that approach, refer to my answer to "How do I model content (types) from a database-centric point of view?".

In the long run, I bet the overall implementation of your entire site would be much better (eg: you'd need way less contributed modules). But that also implies you're willing to do a way higher effort/investment then just adding the Conditional Fields module.