Sharing CCK Fields - Advantages and Disadvantages

It depends on each particular use case. Think about things you cannot do when a field is shared. For example, fields have global settings, and per content type (instance) settings. Field permissions are per field, not per instance, ...

Shared fields are stored in their own tables, so that means more joins when loading a node, but maybe less joins when using a view than list information about several content types.

PS: This is not a CCK3 issue.

Please, look at this page:

http://drupal.org/node/112792

In short: CCK implements 2 storage types: 1) per instance and 2) per field.

When a field is created for a particular content type, CCK creates a per instance table, where the keys are vid and nid, as in nodes, that will be used to store the field related columns.

However, when a field is shared between more than one content type, CCK creates a new per field table, where key are still vid and nid, and moves the data for that field from the per instance table to the new per field table. Now, this new table will store rows for this field related to all content types where this field is shared.

Another reason why CCK may use per field storage is when a field is defined to allow multiple values. CCK needs a per field table where a delta column is added to the primary key. Each row on this table will store a single value, so a node that has a field with 3 values will have 3 rows on this table where deltas are 0, 1 and 2.

When a node is loaded, CCK needs to read data from all tables where fields are stored. It does not use joins, but separate queries for each table required. If all fields in a content type use per instance storage, then a single query is enough. But if there are fields using per field storage, additional queries are required. CCK caches this information, so it does not need to perform these queries every time a node is loaded. These cached entries are cleared when a node is updated or deleted. So the cost of separate tables is somehow optimized and may not impact performance too much.

On the other hand, when you need to build queries to generate reports where CCK fields are involved, the things get a bit more complex as the number of tables increases. This is transparent if you use Views, but still, the complexity of the queries may impact performance significantly. Therefore, per content storage benefit reports where only one content type is involved, but field using per field storage may benefit reports where more than one content type is involved.

In regards to loss of data... every single table is a Drupal installation may break your site. You should make backups and be prepared for disaster recovery. The structure of the database is complex enough with one type of field storage or the other, I think.