Last updated January 2, 2013. Created by Itangalo on May 14, 2012.
Edited by kwseldman. Log in to edit this page.
It is possible to use the same field on more than one entity - for example, an image field can be used on both users and a node type. You do this by using the row add existing field in the list of fields.
When reusing fields, only parts of the configuration, such as help text, may be changed for each node type or entity. Others must be the same for all entities where the field is used, such as number of values to store.
It is recommended to create new fields, rather than reusing existing ones, unless you have a clear reason to do so. The main reasons for this are: you get increased flexibility for field configuration, and shared fields can make it more difficult to export selected parts of the configuration on your site. (See the section on exporting configuration in Appendix 1 for more information about why configuration export is useful.)
TIP: 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 data base 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).
Comments
Good for performance?
Some have arrived to the conclusion that having too many fields can hurt performance big time...
Good points
The points made in the linked post are good – I've updated the tip. Thanks!
Check out Skill Compass – an experiment for Drupal learning.
excessive number of fields
"TIP: From a performance point of view, you don't want to have a gazillion fields."
Is there any reference for what is an excessive number of fields? As a newbie, I have no scale for this.
another Tip: having a lots of
another tip: having a lots of fields will cause problems with many different modules as well. The Token GUI for instance will make you browser lag for minutes if you try to edit url aliases for example. This behavior can be seen on all the pages where token will be loaded and displayed (including devel - dpm() etc.)
There is no performance benefit in splitting this data across multiple table when using InnoDB (MyISAM is different because of table locking). So - if you know you will have a lot of similar content types with similar fields (which configurations will be also the same, maybe differ in labeling only) reuse your fields!
It might also ease up template creation because of similar node attributes.
One benefit of field reuse
There are use cases in which field re-use is preferable. One of these is the need to sort nodes of different content types in a view. For example, a site with content types for general event, scientific event, public event, holiday, announcement (with deadline) may have a requirement for a pane which displays the next three upcoming events or deadlines or holidays. Drupal views have reasonably sophisticated support for grouping and combining filtering conditions, but the support for sorting is less capable of handling complexity. If the date fields to be used for sorting the nodes for these content types are not shared you will have to create separate sort rules, which will mean that the content type whose rule comes first will always sort last (because the nodes of the other content types won't have a value for that rule's field, so an ascending sort puts them at the top of the list). If the next five events/deadlines/holidays are:
then the nodes for April 15-17 should show up in the pane. But if the rule for the deadline field is first in the sorting configuration the other nodes will push both of the deadline nodes off the displayed list altogether. Supposing the order of the sorting rules to be
the pane will show:
If all of these content types use a shared field for the date used for sorting then the requirement can be met.