Nên sử dụng Existing Drupal Fields để tạo Fields mới

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:

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.

This advice is similar to our thoughts on using multi-sites. Whenever you start to build dependencies between codebases or database tables, you add complexity to your site.

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.