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