David Strauss wrote:
Earl Miles wrote:
No, you misinterpreted mine. Drupal is modular. comment.module is a
module. Now, it's a poor module -- it has some rather nasty integration with the rest of the site which, IMO, it should not. But it worries me that one of the solutions is to re-integrate rather than to make it properly modular. I was training someone on some basics of developing a Drupal module last week and we needed to create a module tying data to a node. His initial instinct was to add a new column to {node} and I said "That is not the Drupal way. Drupal is modular so we must create our own table." So we created our own table JOINed to nid.
So, I don't pretend to be a master of all things DB, but what about getting closer to how CCK does a bit heavier manipulation of the DB schema. For example, if you have a CCK field used in more than one content type, CCK creates it's own dedicated table, if just one content type uses that CCK field, those columns go in that node type's table. Especially with the new Schema API, couldn't we allow a module to add/remove/update its own fields to {node}, for example, if it would really improve performance in certain circumstances and as long as we maintain our module's namespace? It would still be modular as we have .install files to do all the magic on install/uninstall. -Rob