Karthik wrote:
On 08/06/07, Derek Wright <drupal@dwwright.net> wrote:
1) {node_revisions} *ALWAYS* has at least 1 record for any given node. that's where title, body, etc are stored. please read the schema if you have further questions. therefore, the only site with an empty {node_revisions} table is the site with no nodes at all.
2) {node_revisions} has an index on nid, and we always JOIN on nid. by and large, the cost of this JOIN is constant, regardless of the # of rows in the table, since the JOINs basically always use the index.
Eh? So what is by and large? Does that mean some queries will be less efficient?
For example, how about if my module in contrib perform an ORDER BY on node_revisions fields such as timestamp and uid? This would require a filesort on the entire table ... Will these be unaffected?
That's a ridiculous, contrived scenario. If your site's small enough, the performance won't change much. If your site's large, you should add a new index on {node_revisions}. You're not going to convince anyone here that the DB should be structured to maximize performance of your hypothetical, ill-conceived queries.
This is essentially:
a) Taking away choice.
Taking away frivolous choices is a good thing.
b) Increasing table size. c) Introducing inefficiency. d) Loading the table with potentially unnecessary junk whether I like it or not.
All three of those are overstatements of the same thing: the DB gets a little better. The increase in size is pretty minor.
e) Asking me to sort any resulting issues out with another contrib module.
It's official policy to completely disregard compatibility issues with contrib.
f) Telling me what's good for my site.
If you're so desperate to not have revisions, you can write a contrib module that deletes all old revisions every time you save a node.
... all for the sake of a couple of checkboxes.
And all the other reasons mentioned in my post. Nice strawman.
No thanks. -1.
-K