Mark Fredrickson wrote:
On the subject of bits on nodes, I would advocate for the least number of hard wired fields as possible. Hardwired data conflicts with user configurable systems and makes administration harder and more confusing for end users. Instead, I would advocate for dynamically added data (from modules) where needed.
In more specific terms, let me argue for removing a large portion of the current node object (feel free to disagree):
From the node table: nid - keep vid - keep type - keep title - remove. Titles should be set by node modules (and stored where the body and teaser are), not stored in the node table.
This was a design decision. We often only need the title of a node (for link lists for example). If we do a join on the node_revisions table, we lose a lot of time. We are contemplating to add the author's name for the same reason (save join on user table).
uid - keep status - remove. Let a module like workflow control the state of the node. Or, don't have a state. Let the admin decide. Node_access is a better solution than an all or nothing published state, in my opinion. created - keep. changed - keep comment - remove. Why would I want this data if I don't allow comments? Spareness should be avoided if we can help it. promote - remove. Let's move nodequeue into core and make a default "front page" queue. This more extensible. moderate - remove. As this thread shows, no one is sure exactly what moderate should do. Let a moderation system control node moderation. sticky - remove. Again, let the nodequeue system decide what is first in the order.
I'd be in favour of a more flexible bitfield instead of all the single fields.
I would also like to see us move away from body and teaser fields in the node_revisions table. If I only use CCK nodes in my site, these fields will be useless for every single node I have.
Then they'll be empty and won't hurt.
If we do move towards an "everything is a node" or at least "most things are a node" model, the body and teaser fields will seem anachronistic.
Well, we don't know if we move there. Also, it would be convenient to store pre-rendered html there...
Yes, this position does require more joins. I understand there is a penalty. I think that penalty is worth the simplicity and can be overcome with better caching.
I am not sure. Getting caching right is a difficult thing and getting queries to perform better is much easier. Cheers, Gerhard