Rob Barreca wrote:
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.
That is generally appropriate for a contributed module. My one-to-one tables post is mostly about *core* tables.
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.
Yes, that is more possible than ever with Schema API. I believe there is already a hook to alter the schema for another module.