[development] Drupal 7 CCK fields in separate tables - why?

[Mukesh Agarwal]

Hi Mike,

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 at 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 at mikeyp.net
>
>


-- 
Cheers,
Mukesh Agarwal
________________________________
Innoraft Solutions <http://www.innoraft.com>  || +91 8017220799
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20111020/069b4aa0/attachment-0001.html