Re: Drupal 7 CCK fields in separate tables - why?

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
[email protected]