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]
