I've spent the better part of the day reading as much as I can on how CCK works and dynamically builds tables for its content types and fields. I'll ask my question through my scenario.

If I create a new content type, a table in the database is created called CONTENT_TYPE_HOUSES (one of my content types is 'houses' - my site is a classifieds website). If I add a CCK textfield called "price" (float) well, then inside my content_type_houses table, there is a new field called content_field_price.

When I create my CARS content type, I get a new table CONTENT_TYPE_CARS. Great. Expected.

What I didn't expect is that when I shared the "price" field between houses and cars, the field was extracted, tables rewritten, instance tables, updated, and a one to many relationship created with a completely new table for the price field. So a one to many relationship for each content type.

Then, I added, and shared between the two content types an image filefield for photo uploads, and I set the settings to allow an unlimited number ( so long as the max post size was less than 10M ).

So my questions are, if I understand everything correctly, in addition to the field instance table, Is this not a 1 - m, m - m relationship nightmare? How would you even begin to optimize this? And why go through the trouble if CCK or possibly other modules can simply rewrite your entire database on the fly? (good by efficient indexing, goodbye query caches, since the queries obviously have to change constantly to suit the needs of the new table structures).

Would it not be more efficient to simply create a uniquely identified "price" and other cck fields for each content type? Or, better put, not share fields at all?

I shared fields simply to save the few minutes of having to retype them, and reduce their redundancy. This is concerning me because I'm migrating data from another database to drupal. I only have a few hundred records and already my performance has been crippled. In fact, my modules page times out and uploads via forms, especially the ones that share fields are taking way too long, and on top of that it's not uncommon for my Views queries to take up to 18 seconds before they load

I fully intend on doing my own tests, but I'm hoping someone has already thought about this, or has any experience testing this or a similar theories. After the migration nightmare I've been having (please see my posts under tracking for more info), I don't want to have finally uploaded these 100,000 CCK driven nodes only to realize that an extra 10 minutes of creating redundant fields for each content type could have made my pages 10x faster.

Any thoughts?

thanks,

blue

ps machine is local server, 2gig cpu, 4 gigs ram.

Comments

ancky’s picture

subscribe

nevets’s picture

Consider the three ways you get a field in it's own table

a) The field is shared, this can be a plus when it comes to views (you can list the different content types that share the field and display the field, if not shared it's more work).

b) The field allows for multiple instances, the separate table is really the way to go.

c) Because the field type chooses to :). Tends to be for complex/multi-value field types and generally makes sense for these cases.

Since the tables are keyed I would guess that the extra time to join the tables is minimal.