First, you should consider software boundaries that may affect your choice. In a list you can have a max of 32 choice fields, and 16 lookup fields (check http://social.technet.microsoft.com/wiki/contents/articles/12438.sharepoint-2013-best-practices.aspx#Capacity_Planning for details).

Next you must consider the requirements of your current and likely future projects when deciding which column types to use. The following table will help you evaluate the pros and cons of each column type.

 

Column Type  Pros  Cons   Conclusion
Choice Column
  • Self-contained, not affected by changes elsewhere
  • Can have a default value set in list/library settings
  • Selectable within Quickparts added to Word documents, even in older Word versions
  • Can be used as values in calculated columns.
  • Easiest to use in SharePoint Designer workflows.
  • Easy to manipulate programmatically

 

  • Updating one of the values does not force that change on all items tagged with the value; you need to make manual changes to each item to correct.
  • There is no way to constrain deletion of values in use.
  • User must have rights sufficient to change list settings to update the column (in certain circumstances, this could be a 'pro')
  • By default, choice columns are not automatically promoted to search refiners; manual steps requiring a high level of user rights must be completed to enable this
  • Using OOB SharePoint UI, cannot remove a value from tagging options going forward without deleting the value from the choices.
  • Data cannot easily be pulled in from external sources to populate choice column
  • Choice columns do not support hierarchical relationships
  • Values cannot be merged
  • Cannot add synonyms
  • No autosuggest feature
Choice columns should be used for local (list level) columns that will not change frequently or for site columns that have no search refiner value.

Choice columns should not be used for lists that are likely to get very large unless it is extremely unlikely that the values will ever change.

Regardless of the above, you may need to use a choice column if your requirements call for the field to be evaluated or manipulated in a calculated column.
Lookup Column  
  • Easy for end users with contribute rights to maintain. 
  • Can constrain deletion of values in use
  • Data can be pulled in from external sources fairly easily
  • Updating a value in the lookup list forces the chance down to all items that are tagged with that value
  • Easy to use in SharePoint designer workflows.
 
  • Default value cannot be set at the list/library level.
  • Cannot be selected within Quickparts in some older Word versions.
  • More complicated to manipulate programmatically than choice values
  • Using OOB SharePoint UI, cannot remove a value from tagging options going forward without deleting the value from the lookup list
  • By default, lookup columns are not automatically promoted to search refiners; manual steps requiring a high level of user rights must be completed to enable this
  • You must be careful to place your lookup list at the correct level in the site collection so that all sites needing to use the data in site columns can inherit it.
  • If you wish to make your lookup available across site collections, you must create it in the content type hub, which requires special rights to access
  • Lookup columns do not support hierarchical relationships
  • Lookup column values cannot be used in calculated columns
  • Values cannot be merged
  • Cannot add synonyms
  • No autosuggest feature
Lookup Columns are the best choice if you have master data in another location (such as a SQL database) and want to use it as metadata in SharePoint.

Lookup columns are also an excellent choice in environments where you don't have the support, time, or budget to undertake an organization-wide taxonomy effort but you want to standardize at the site collection level.

Lookup columns at the site level that users can add to are a great way to see how they categorize their information and can be used later as the starting point for a formal taxonomy via the term store.

If you need to use a lookup column value in a calculation, you will probably need a workflow to meet your requirements.


Managed Metadata Column
  • Supports hierarchical relationships and rollups
  • Changes in a value are pushed down everywhere the tag is used
  • Can add synonyms that are used in search and when tagging
  • Individual terms can be hidden from tagging interfaces if they are no longer in use
  • Automatically promoted to search refiners
  • Default value can be set at the list/library level
  • Automatically suggests terms as the user types based on input
  • Hierarchy is flexible and can be changed without breaking connections to tagged items
  • Do not display easily in emails produced by SharePoint designer.
  • Hardest to manipulate programmatically.
  • More difficult to populate based on external data.
  • Managed metadata values cannot be used in calculated columns.
  • Cannot be selected in Quickparts in older Word versions
  • Requires careful planning and centralized curation by trained staff familiar with the business processes of the entire organization.

 

Managed metadata columns based on the SharePoint term store are the hands-down choice for managing organizational taxonomy and tagging, especially across site collections. 

In addition, Managed Metadata columns provide the best OOB search experience.

If you need to use Managed Metadata columns in calculations, plan to spend some time and effort on workflows and other workarounds.

Likewise, you will need custom solutions to pull data from other databases into the term store.

 

See Also

See SharePoint 2013 Best Practices: http://social.technet.microsoft.com/wiki/contents/articles/12438.sharepoint-2013-best-practices.aspx#Capacity_Planning


Other Languages

This article is also available in the following languages :