Posted by robertDouglass on March 7, 2007 at 1:47pm
I just published a pretty long and thorough article describing the basics of CCK inner workings:
http://www.lullabot.com/articles/an_introduction_to_the_content_construc...
Hope you like it, and hope it is useful.
Comments
cck performance for shared fields and fields with multiple value
Hi Robert,
thanks very much for a very useful article.
in reading it, I draw these 2 conclusions
1) for performance, i should not share fields. eg. have "first name for profile" and "first name for review" instead of having one first name field. this will lead to an extra join ,is that right?
2) similarly, i should try to avoid multiple values.
i have some fields that are multiple select with 10 values.
are you saying they will be stored in 10 tables? (sorry if i misunderstood)
i have some long cck node types with A LOT OF 50 fields
it's good to use cck in that it's very easy to rearrange the fields and edit fields.
I would say, be true to the model first, and fix performance
if it becomes a problem. There are good reasons for sharing fields across node types. What if you modeled 3 types of People with 3 different content types, and each one was supposed to have an Age field; how would you find the average age of all your people if the fields were all different?
If you don't need multiple fields, don't use them. But if your data model suggests multiple values would be the right fit, don't shy away from them just because of a join. I've not seen joins be the cause for databases crashing or huge performance hits. Much more critical are indexes and locking.
What's more, content module
What's more, content module caches the set of field values for each node - so the additional JOINS induced by shared or multiple fields only happen when the node has changed. Subsequent node_load calls just retrieve the values from the cache in one simple query.
(edit : Views-generated queries will require the additionnal joins, though...)
As Robert said, set up your fields as you logic and semantics require :-)
And thanks Robert for this article - maybe a word should be added on the caching part, in order to ease some of the readers' worries about performance ?
caching++
I'm already working on a second article =) I'll get there.
Keep them coming, Robert, it is a great contribution!
Very insightful article, as I said in my post on Lullabot; apart from the very welcome newbie technical details and the clarity of exposition, at the core of your article is a model perspective (as evidenced by your answer above concerning fields used to normalize references among multiple content types) that actually stands head and shoulders above mere CMS: I believe it could become a germ of a semantic form of organizing design and implementation which is actually superior to the merely empirical "binding by naming conventions" Ruby on Rails approach: your philosophy is closer to classic ORM (object relational model) which, if developed in the times to come, could give Drupal "Hibernate-like" power... and that would put it on a true application level pedestal.
On a more mundane note, I hope to read more in your coming series about how to exploit CCK; the first would be of course, how to write a CCK field module, that would be cool.
Thanks again,
Victor Kane
http://awebfactory.com.ar
Victor Kane
http://awebfactory.com
cck, caching
thank you all for the useful comments.
I will keep in mind the issues of keeping the data consistent, as well as the problem that views-generated queries will require joins.
My test site has run out of memory (at 20MB) so I am concerned about performance.
I wonder if you can write an article about caching and Drupal. It appears to be the source of a lot of confusion, but there does not seem to be a clear write up in the handbook.
With that as background, it will then be easier to understand the issues involved in cck and performance.
Hi lapur. Just briefly,
Hi lapur.
Just briefly, memory is not necessarily tied to performance. PHP loads your files (memory) but (for an absurd example) might only execute 10 lines of code.
Without labouring on a solution, you could simply check if there are any modules you are not using and uninstall them.
(Robert: damn fine article!)