[development] One-to-one tables considered harmful

[Vladimir Zlatanov]

>
> >> 1. Is it kosher to add columns to other modules' tables? E.g. Is it ok
> >> for comment to add it's statistics to the node table. Similarly, I
> >> could imagine the stats module would want to add summary information,
> >> and perhaps other modules as well.
> >
> > At one point we had a 'field' op to nodeapi that let modules add fields
> > to the node table. I would like to see this restored.
>
> What about the upgrade path arguments I mentied above in the thread? Or
> if those are taken care of somehow, why only have this for nodes? :P


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.

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.Thespace overhead can be significant.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070606/a57bc96b/attachment-0001.htm