Designing different content types with the same fields' name (shared fields)

Question

For my website I need several content types (at least five), but all that have some fields' name in common as title, subtitle, body, teaser, image and so on.

Shall I use the same field (machine name) for all the content types or is better an its own field for each content type?

For example, if I have the two content types "articles" and "recipes" and create the field "field_subtitle", shall I use this field for both content types or is better to create the two fields "field_articles_subtitle" and "field_recipes_subtitle"?

Are shared fields better or worst in term of performance?

Answer 1

Performance isn't a huge issue in my opinion, the advantages you will gain from having correctly built relational data will outweigh any performance gains.

Use the same field across your different content types. If you are storing the same "thing" then semantically using the same field has many advantages.

1. Doing things that are common to that field work across content types. Eg, pulling out the subtitle and displaying it under the H1 in the page template.
2. Some common settings across the entities. This means that if you know a subtitle will never exceed 200 characters, you need only enter this one, keeping your models a little more dry.
3. If you would like to ever list these things together, you can use views to list the common fields with no extra effort.
4. CSS can be written more generically. Subtitles are usually grey and italic, this can be applied across bundles or entities much easier if the fields are common.

There are some disadvantages of creating lots of fields across entities to represent the same data:

1. Messy field lists and lots more database tables. While this wont have too much of an impact on performance, it's simply a technical debt that can be avoided.
2. Messy code. Having to reference ->field_articles_subtitle vs ->field_subtitle is simply duplicating information we already know (that we are working with an article).

In terms of CSS, if you would like to define custom types of formatting to different entities you can always use:

.node-type-article .field-field-name{ custom-css: true; }

In short, for the example you stated use the same field.

Answer 2

As a general rule, I don't share fields unless they are being shared on entities that are part of the same section (or feature if that makes it easier)of my site.

For example, if I need an Entity Reference field that links to users on both a Blog content type and a Blog taxonomy term (I'm not sure why I would, but I can't think of a better example at the moment), then I would probably share it. If, however, I then wanted a field exactly the same on my News content type (i.e. one that references users), then I would create a new field. This means that my blog and news "sections" are independent of one another.

I haven't ever run any performance benchmarks or anything, this is jsut a personal preference that means if I bundle my site config up as a Feature using the Features module, there aren't any conflicts between my Blog and my News features.

On another note if it helps illustrate my point, I also tend to name my fields with a view to where they're being used wherever I can (e.g. field_blog_userref or field_blog_header_image)

EDIT

If you're concerned about making your CSS easier/harder, then even with seperate fields you can give them the same markup/CSS classes with the Fences module.

Fences is a an easy-to-use tool to specify an HTML element for each field.

So you could have two different fields, but you can give them both the class .my-text-field to make styling easier :-)

Answer 3

The big question is - are those field supposed to hold the same data? If yes, then do reuse. Subtitle for article is the same, from business point of view, as subtitle for recipe. They probably are going to be themed the same way, to be searchable (or not) the same way, and so on.

On the other hand, if fields share name by pure coincidence, like "icon" as a religious work of art and "icon" as a small graphical representation of a computer software, keep them separate, with names like icon_art and icon_software.

For performance, if your server caches data in a reliable way, it shouldn't matter.

Answer 4

Another consideration that hasn't been mentioned is whether the fields are going to require different settings in the different content types. Some settings (such as label text) can be set per-content-type but others such as cardinality apply across all.

So if only one subtitle can be entered in content type A but content type B can have more than one, then you need to have two separate subtitle fields.