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

[Mukesh Agarwal]

Thank you Ernst for the advice.

I think we could have achieved different revisions for each field by marking
a field in UI as something that requires revision which would mean only
those fields that require a different revision can do that. Same goes for
translation. I think the entire field entities API is nice and makes
programmers life easier. But in trying to make things generic, we have added
a lot of overhead on Drupal core - content management system.

Using MongoDb is a good option. I like the idea but since the support system
for the same is not that strong, I'm sure clients will have a concern.

I'm not sure if I want to chuck Drupal as a solution to our problem. Will
have to find different ways.

Not convinced with the separate fields idea though.

On Thu, Oct 20, 2011 at 11:25 AM, Ernst Plüss <ernst.pluess at gmail.com>wrote:

> 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
> >
>



-- 
Cheers,
Mukesh Agarwal
________________________________
Innoraft Solutions <http://www.innoraft.com>  || +91 8017220799
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20111020/31eb5a21/attachment.html