[development] Drupal 7 CCK fields in separate tables - why?

[Ernst Plüss]

I know of two reasons why this is:

1. You can have different revisions by field.
2. You can translate by field

By normalizing the DB tables this is much easier to accomplish.

BUT: You are right DB performance, especially write performance is
very bad. I've seen a big drupal project failing because we had about
300 DB tables for a lot of fields.

If you have big and complex data structures the standard field
implementation of Drupal 7 will not make you happy. I think you have
the following options:

1. Use MongoDB. There is a fields storage engine module in Drupal 7.
The only problem I see is much less mature DB system than MySql or
Postgress DB.
2. User entities API. This is of course much more work, especially if
you have to write alle the views and may be fields integration.
3. Look for something else then Drupal. Currently we go for Ruby on
Rails with Hobo for projects with a lot (>10-200) business entities.

HTH
Ernst



2011/10/20 Mukesh Agarwal <mukesh.agarwal17 at gmail.com>:
> Hi Everyone,
> I'm sure I'm asking a question that people might have been asking for long.
> Please bear my ignorance on following all the development threads.
> I'm right now designing information architecture for one of my clients in
> Drupal 7 and it turns out that there are many attributes associated to the
> entities. Now that CCK fields are all stored in separate tables, my node
> pages now have sql queries that have numerous joins and the performance goes
> for a toss.
> Does anyone know a good reason for moving from the previous schema? Single
> valued cck fields are in the content type and multiple valued fields form a
> new table. What was wrong with that?
> --
> Cheers,
> Mukesh Agarwal
> ________________________________
> Innoraft Solutions  || +91 8017220799
>