Quantcast
Channel: Recent posts across whole site
Viewing all articles
Browse latest Browse all 49221

What's the point of shared fields, anyway?

$
0
0

I've been reading many posts about cck's shared fields and performance, and they all agree in one thing: Do not use shared fields unless strictly necessary. The fact is i have never found the need for them, and I've been working with CCK for some years now...

Ok, it's easier to set up if you need the same field in many content types, but this could easily be handled by a "Clone field" button in the interface. If you use a shared field, you have to configure the new field settings anyway, so there is no need to add all the cons shared fields have just to save a click. I feel this is just an interface thing, it's a little crazy to alter the DB structure of a site just to make the field creation process simpler.

The cons of shared fields:
- More JOINs -> less performance
- A more complicated table structure in DB -> more difficult to import/export/debug/understand/etc.
- You cannot reuse the same (non-shared) field name in different content types (see below)

Besides, there are some situations in which shared fields just add a lot of complexity. For instance, i have recently tried to set up a view using the reverse nodereference field to fetch data from several "child" content types, all referencing a "parent" content type. If a shared nodereference field is used along all the child content types, the reverse nodereference module is unable to tell one content type from the other, which screws up the joins.

In this case, i had to set up different nodereference fields for each of the child content types, but this is a pain in the ass, since you cannot use the same field name, and have to do something like "field_parent_<child_node_type_name>" (instead of just "field_parent"), which makes the code much more complicated. If fields would belong only to a certain content type, this could lead to reusing the same field name among content types (as the field cannot be shared, it can be defined by content-type-name>field-name, thus field-name can be the same for different content types). This would make the code much cleaner, with no impact on performance, and (with just a "clone field" button) it would be just as easy to setup.

So i guess my question is... is there a certain situation in which you really need a shared field? Couldn't we just get rid of them and make a field namespace for each content-type, and a "clone field" button?


Viewing all articles
Browse latest Browse all 49221

Trending Articles