the real benefit is that there is no longer
any fancy logic around determining what table a field will be stored in
Removing the small piece of fancy logic does not really cover up for the overhead multiple tables create.
Your first point should have been to just install Entity cache
<http://drupal.org/project/entitycache> and be careful how you load
entities.
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.
On Thu, Oct 20, 2011 at 11:38 AM, Michael Prasuhn
<mike@mikeyp.net> wrote:
Ernst Plüss wrote:
> I know of two reasons why this is:
>
> 1. You can have different revisions by field.
> 2. You can translate by field
#1 was possible with CCK, the real benefit is that there is no longer
any fancy logic around determining what table a field will be stored in.
While EntityFieldQuery would be possible without this, it is somewhat
easier with consistent per field storage.
> 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.
Your #2 doesn't make any sense. Nodes are already entities and fields
are fields regardless of what entity/bundle they are attached to.
Your first point should have been to just install Entity cache
<http://drupal.org/project/entitycache> and be careful how you load
entities.
If you think custom development with Rails (and designing your own
models) is less work than carefully enabling a few modules and clicking
through the fields UI, then I don't know why you would ever even try
Drupal in the first place.
-Mike
__________________
Michael Prasuhn
503.512.0822 office
mike@mikeyp.net
--
Cheers,
Mukesh Agarwal
________________________________