<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">>> 1. Is it kosher to add columns to other modules' tables? E.g. Is it ok<br>>> for comment to add it's statistics to the node table. Similarly, I
<br>>> could imagine the stats module would want to add summary information,<br>>> and perhaps other modules as well.<br>><br>> At one point we had a 'field' op to nodeapi that let modules add fields
<br>> to the node table. I would like to see this restored.<br><br>What about the upgrade path arguments I mentied above in the thread? Or<br>if those are taken care of somehow, why only have this for nodes? :P</blockquote>
<div><br>That's a very valid point. It can be solved, especially with the introduction of $schema, it becomes a variation on the *_alter theme, but at install/upgrade and module enable/disable times. The downside that it becomes far more complicated to track relations and conflicts between modules.
<br></div><br></div>A compromise can be achieved by having index caches - tables which serve only for the purpose of maintaining fast indexes, so the various where and order clases are executed on these tables only, so that unnessesary temp tables are avoided. Again, it complicates the design, and special attention has to be paid for the consistency of the caches, which can very
brittle.The space overhead can be significant. <br><br>The problem we have is where to compromise. We have a very dynamic system, where the types can be changed at different points in time, and static db schemas. How do we maintain the mapping between the two and keep it efficient without major sacrifices in either?
<br>