A quick summary of my thoughts on this; I disagree with some of the recent posts that seem to suggest putting all dupal "'objects" into one table. This has the same drawbacks as making everything a node. I'd much rather see an effort to build a single consistent API for all core and contrib-defined objects. Each of these object types would still have their own primary table (and possibly a revisions table). For example, rather than doing node_load(), user_load(), comment_load, etc, I'd like to be able to do: $node = drupal_load('node', $node_id); $user = drupal_load('user', $user_id) ... Assume $class = 'node', then when loading a node drupal_load() would call something like: $object = db_fetch_object(db_query("SELECT * FROM {%s} WHERE %s_id = %d", $class, $class, $id")); $extra = module_invoke_all($class .'_load', $object); The node module would declare a function (e.g. node_class_define()) that would return a list of all the fields in the node table for saving/inserting. Modules could optionally also define type object for their objects (i.e. node_type objects). This would mean any contrib module could define this one function and install the table and automatically get all the load, save, hook, etc. code for free. Menu module could even automatically define a standard set of non-cached paths and tabs like $class/$id/edit $class/$id/view $class/$id/revisions for each module that defines a drupal object, making the devel's life even easier. Anyhow, obviously the devil's in the details, but this sort of unified API seems much more valuable to me rather than tying to deny the uniqueness of each type of data by throwing them all in one enormous object table. This would seem also to move towards getting more of the advantages of OO programming, without getting hung up on the different support for objects in different PHP versions. -Peter