Am Montag, den 22.01.2007, 09:54 +0100 schrieb Bèr Kessels:
I don't like the idea of storing a 'thing' in one table alone. Its not good for performance and horrible when you want to normalise your data.
I also don't like the idea of a big object table - I just don't see a need for this. I would prefer the pair of type string like node/user/vocabulary/.. with its ID, unique only for its type. I see three pros for this approach: * better performance * easier upgrade from currently existing databases * easier readable object references as you have the type
Therefore, I think its a much better idea to go the Active Records route: Define good defaults/standards and provide APIs that can pull information from these standardised tables
standardized tables are one way. Personally I don't like it that much. I think it would be more visible and flexible, if object type properties are clearly stated somewhere e.g. by a hook which aggregates object type definitions. I also want to point to this interesting issue related to this discussion: http://drupal.org/node/79684 Strategy 3 comes close to the "drupal object" idea. I would go and create the functions drupal_create() drupal_read() drupal_update() drupal_delete() with appropriate arguments. e.g. drupal_read('node', array('nid' => 42)); Then we could go and generalize the node API to work with all drupal objects. But probably it's not necessary or useful to apply the full node API to every drupal object, e.g. the node access system. So perhaps it would make sense that the object type declaring module states, which capabilities the object type has. This could be done with the above mentioned object type definitions, which are parsed from the API. So we could create object types with appropriate capabilities and appropriate resource usage. Basically this is the idea I have in mind, however this needs to be elaborated further. regards, fago