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
________________________________