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 <[email protected]>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 <[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 > > > -- Cheers, Mukesh Agarwal ________________________________ Innoraft Solutions <http://www.innoraft.com> || +91 8017220799
