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