#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 * [email protected]* | Gtalk *podarokua* | AIM *podarokua* | | | | *Меня не интересует, почему «нет», меня интересует, что нужно сделать для того, чтобы было «да»*
2011/10/20 Ernst Plüss <[email protected]> > 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 <[email protected]>: > > 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 > > >
