Karthik wrote:
You *completely* missed the real argument:
Drupal is modular. Modules tend to have their own tables. Often these are 1::1 tables.
You misinterpreted my post. I said the 1::1 tables created by content types are fine. We're talking about core tables here, like {node_comment_statistics} that have columns often used in WHERE or ORDER BY criteria.
I think Earl does not want you to make any such discrimination. IMO, you're compromising design integrity for performance. The comment module is, whilst still a core module, an *optional* component. Some installations/distributions might use it. Some installations might not. Some installations might have a drop in replacement for it. For e.g., the project module, IIRC, does not use the comment module and still uses its own table.
Please explore how Drupal core functions before you make such claims. The tables exist for all core modules regardless of whether they're enabled or not. So, it is irrelevant that comment is an optional module.
I believe that Weitzman has an existing issue for this as well. There is also another issue or mailman thread proposing that the url_aliases table be merged into the node table for similar reasons. Let's just invite everybody in, shall we?
Yes, if it improves performance without compromising design.
How is the comment module different from other modules - core or contrib - in similar situations? Should this (inserting/removing fields into/from the node/taxonomy/user/x tables in .install) become the rule of thumb to streamline any queries that result in temporary tables?
Well, the comment and node tables are different in that they're system-owned tables.