Thank you Ernst for the advice. <div><br></div><div>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. </div>
<div><br></div><div>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. </div><div><br></div><div>I'm not sure if I want to chuck Drupal as a solution to our problem. Will have to find different ways. </div>
<div><br></div><div>Not convinced with the separate fields idea though. <br><br><div class="gmail_quote">On Thu, Oct 20, 2011 at 11:25 AM, Ernst Plüss <span dir="ltr"><<a href="mailto:ernst.pluess@gmail.com">ernst.pluess@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I know of two reasons why this is:<br>
<br>
1. You can have different revisions by field.<br>
2. You can translate by field<br>
<br>
By normalizing the DB tables this is much easier to accomplish.<br>
<br>
BUT: You are right DB performance, especially write performance is<br>
very bad. I've seen a big drupal project failing because we had about<br>
300 DB tables for a lot of fields.<br>
<br>
If you have big and complex data structures the standard field<br>
implementation of Drupal 7 will not make you happy. I think you have<br>
the following options:<br>
<br>
1. Use MongoDB. There is a fields storage engine module in Drupal 7.<br>
The only problem I see is much less mature DB system than MySql or<br>
Postgress DB.<br>
2. User entities API. This is of course much more work, especially if<br>
you have to write alle the views and may be fields integration.<br>
3. Look for something else then Drupal. Currently we go for Ruby on<br>
Rails with Hobo for projects with a lot (>10-200) business entities.<br>
<br>
HTH<br>
Ernst<br>
<br>
<br>
<br>
2011/10/20 Mukesh Agarwal <<a href="mailto:mukesh.agarwal17@gmail.com">mukesh.agarwal17@gmail.com</a>>:<br>
<div><div></div><div class="h5">> Hi Everyone,<br>
> I'm sure I'm asking a question that people might have been asking for long.<br>
> Please bear my ignorance on following all the development threads.<br>
> I'm right now designing information architecture for one of my clients in<br>
> Drupal 7 and it turns out that there are many attributes associated to the<br>
> entities. Now that CCK fields are all stored in separate tables, my node<br>
> pages now have sql queries that have numerous joins and the performance goes<br>
> for a toss.<br>
> Does anyone know a good reason for moving from the previous schema? Single<br>
> valued cck fields are in the content type and multiple valued fields form a<br>
> new table. What was wrong with that?<br>
> --<br>
> Cheers,<br>
> Mukesh Agarwal<br>
> ________________________________<br>
> Innoraft Solutions || +91 8017220799<br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Cheers,<div>Mukesh Agarwal</div><div>________________________________</div><div><font color="#999999"><a href="http://www.innoraft.com" target="_blank">Innoraft Solutions</a> || </font><span style="color:rgb(153, 153, 153)">+91 8017220799</span></div>
<br>
</div>