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 >
