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

Michael Prasuhn mike at mikeyp.net
Thu Oct 20 06:29:39 UTC 2011

Mukesh Agarwal wrote:
> 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.

Actually Entity cache does not pay any regard to whether a user is
logged in or not, or even users at all. What it does is cache the fully
loaded entity, after it has been loaded from the database (however many
tables are required). This means that the first time you load a node you
will hit all the necessary tables including node, node_revision, user,
all the fields tables, etc and the node object is stored in the cache.
Subsequent calls to load that node will retrieve the fully loaded node
object from the cache instead of using the node and field tables. The
module is also able to determine when changes are made to the node
through hook_entity_update and clear/expire the cache accordingly.

The Entity cache module works very well logged in users. (If entity
loading is truly the source of your performance problems)

Michael Prasuhn
503.512.0822 office
mike at mikeyp.net

More information about the development mailing list