Hi Mike,<div><br></div><div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
the real benefit is that there is no longer<br>any fancy logic around determining what table a field will be stored in</blockquote><div><br></div><div>Removing the small piece of fancy logic does not really cover up for the overhead multiple tables create. </div>
<div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
Your first point should have been to just install Entity cache<br><<a href="http://drupal.org/project/entitycache" target="_blank">http://drupal.org/project/entitycache</a>> and be careful how you load<br>entities.</blockquote>
<div><br></div><div>Entity cache does not help me in case of logged in users. The application I'm developing now is an enterprise app. IMO, caching also does not cover up for multiple tables overhead. I'm sorry if I've misunderstood the workflow of entity cache module but from what it seems, this is just a caching technique for entities. </div>
<br><div class="gmail_quote">On Thu, Oct 20, 2011 at 11:38 AM, Michael Prasuhn <span dir="ltr"><<a href="mailto:mike@mikeyp.net">mike@mikeyp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Ernst Plüss wrote:<br>
> 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>
</div>#1 was possible with CCK, the real benefit is that there is no longer<br>
any fancy logic around determining what table a field will be stored in.<br>
While EntityFieldQuery would be possible without this, it is somewhat<br>
easier with consistent per field storage.<br>
<div class="im"><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>
</div>Your #2 doesn't make any sense. Nodes are already entities and fields<br>
are fields regardless of what entity/bundle they are attached to.<br>
<br>
Your first point should have been to just install Entity cache<br>
<<a href="http://drupal.org/project/entitycache" target="_blank">http://drupal.org/project/entitycache</a>> and be careful how you load<br>
entities.<br>
<br>
If you think custom development with Rails (and designing your own<br>
models) is less work than carefully enabling a few modules and clicking<br>
through the fields UI, then I don't know why you would ever even try<br>
Drupal in the first place.<br>
<br>
-Mike<br>
<br>
__________________<br>
<font color="#888888">Michael Prasuhn<br>
503.512.0822 office<br>
<a href="mailto:mike@mikeyp.net">mike@mikeyp.net</a><br>
<br>
</font></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>