Should I Re-use Existing Drupal Fields?

Should I Re-use Existing Drupal Fields?

Drupal gives you the ability to re-use fields. If you have an "Image" field, you could choose to use that same field on every content type on your site.

However, it's not always clear whether re-using fields is a good idea. Sometimes it is, sometimes it isn't.

Here's an overview of the advantages and disadvantages to consider before re-using Drupal fields.

General advice on re-using fields

You can choose the "Add existing field" feature whenever you go to Structure > Content types > Manage fields:

The Drupal.org documentation does not recommend that you re-use fields:

"It is recommended to create new fields, rather than reusing existing ones, unless you have a clear reason to do so".

That's also the general consensus amongst Drupal professionals that I talk with. There's nothing inherently wrong with re-using fields, and it can be a useful approach in some situations, but it can also cause more problems than it solves.

Advantage: simplicity and time-saving

The Drupal Field UI documentation says this:

"reusing fields can save you time over defining new fields."

That's true, but the time-savings are very small. A more compelling advantage is that re-using fields can sometimes make site administration simpler. Web Initiative sum this up nicely:

"Reuse of fields can also reduce the system’s complexity. Instead of creating and maintaining 10 different fields, Drupal admins maintain only two fields and their documentation. Database administrators only need to improve performance of two extra tables. KISS is always a good principle."

It definitely would be easier to apply permissions, setting and design elements to one re-used field rather than 10 unique fields.

Advantage: some content works well with re-used fields

Back to the Drupal Field UI documentation again:

"reusing fields also allows you to display, filter, group, and sort content together by field across content types. For example, the contributed Views module allows you to create lists and tables of content. So if you use the same field on multiple content types, you can create a View containing all of those content types together displaying that field, sorted by that field, and/or filtered by that field."

One comment writer on the Drupal.org documentation makes the same point about Views. They point out that Views can combe content in sophisticated ways. So, if you have multiple different content types, with different date fields, then Views can combine them into a single view. However, they also point out that Views isn't so sophisticated with sorting. So, if you have multiple different content types, with different date fields, then Views will struggle to sort the content on all those different date fields..

Disadvantage: Re-used fields are inflexible

Brandon Williams on Twitter summed this up nicely:

"at first it's a good idea, but give it a few weeks, reqs change, you end up creating separate ones anyway"

To a large degree, if you choose re-used fields, you are limiting the changes you can easily make to your data later.

Disadvantage: Re-used fields make data harder to export or migrate

Re-using fields could become an issue when you need to export your data or when you need to migrate to a new version of Drupal or another platform.
Each Drupal field has it's own database table, as shown below. Extracting that data can be tough. The Features module (the most common way to export Drupal data) struggled for a long time with shared fields, although current versions can handle them more effectively.

Whenever you start to build dependencies between codebases or database tables, you add complexity to your site.

Advantage or disadvantage? Performance

The Drupal documentation outlines one possible benefit of re-using fields:

"From a performance point of view, you don't want to have a gazillion fields on your Drupal site. If a content type (or other entity) has a lot of fields, saving the content will result in a lot of database writes that might take time. Also, the field configuration itself might take a lot of memory to load from the cache (and that is done pretty often)."

This thread on Stack Overflow has a very relevant discusion on performance. It includes this comment:

"A real problem however is the number of fields you have. Because currently in Drupal 7, the complete field configuration of all fields, no matter if they're loaded or not, is fetched from the cache on every single request. I've seen sites with 250+ fields, where loading and unserializing the field configuration takes 13MB+ memory." (that has been improved with Drupal 7.22)

So, re-using fields could possibly give small performance improvements by letting us have a lower total number of fields.

However, those small improvements may lost elsewhere. This from Web Initiative again:

[fields] extra complexity to a Drupal system. When creating a new field, the field’s definition is added to the field class table and the field’s configuration is added to the field instance table; meanwhile, a new table is added to the Drupal database to store the field data. Database tables add complexity to the system. In addition, queries of nodes will incur JOINexpressions of tables to field data. Multiple JOINs will impact database performance since MySQL responds poorly to queries with multiple JOINs of tables if not properly configured."