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

[Andriy Podanenko]

#4 Or You can use http://drupal.org/project/properties or something like
that for a huge fields data
*
---------------------------------------------------------------------------------------------------------------------------------------------------------
*
*Andriy Podanenko*
*podarok@ + podarokua@ + podarok_ua@*
Own Blog <http://my.ukrweb.info/blog> | Homepage <http://podanenko.com> |
Twitter <http://twitter.com/podarok> |
LinkedIn<http://www.linkedin.com/in/podarok>|
Profeo <http://www.profeo.ua/podarok> |
vKontakte<http://vkontakte.ru/podarokua>|
Connect <http://connect.ua/user-657054> |
Facebook<http://www.facebook.com/podarok>|
FriendFeed <http://friendfeed.com/podarok> | Drupal
ID<http://drupal.org/user/116002>| Drupal
UA ID <http://drupal.ua/users/podarok> | Yahoo
ID<http://pulse.yahoo.com/_3SZUYBNZG4OQJCUJOZYF2D3UJY>|
SlideShare <http://www.slideshare.net/podarok> |
Delicious<http://www.delicious.com/podarok>| Live
ID <http://cid-3c79f9bdf923693a.profile.live.com/> | Google
ID<http://www.google.com/profiles/podarokua>|
Formspring <http://www.formspring.me/podarokua> | Digg<http://digg.com/podarok>|
WMID *560874932971* | ICQ *499918925* | YahooIM *podarok_ua* | Jabber *
podarok at jabber.org* | Gtalk *podarokua* | AIM *podarokua* |  |  |  |
*Меня не интересует, почему «нет», меня интересует, что нужно сделать для
того, чтобы было «да»*



2011/10/20 Ernst Plüss <ernst.pluess at gmail.com>

> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20111020/8344fe9e/attachment.html