+1 for Triggers and Views. Shared hosting will catch up soon enough. They are not using it now because while MySQL 5.1 is labelled as stable it is not actually production ready. There are performance issues that are getting in the way of any large deployments. Though it's close.

The challenge with (a) is that rewriting query strings is a world of hurt. In D7 now that we have a real good database API that uses PDO means that db_rewrite_sql() and hook_db_rewrite_sql() are gone (hurrah).

I can't say that I'm a big fan of Stantale's proposal. Having an extra record in the table each time a record is edited makes for a big table for no reason. This would be really bad for high-performance sites for two reasons. First this means an update query and an insert query for each edit. I think with a Trigger system writing to an additional table this hit would be lessened. Still not really ideal. Something that works with MySQL binary logs would be better. But this would exclude shared hosting all together. Secondly simple SELECT queries to a table with 10million rows is much slower than the same query to .5million rows. You also need more memory to avoid temp tables swapping to disk. Stantale offers objection to multiple tables on the argument that a query to both the main table and the log table would be complex. I can't offhand think of a use case for this. Perhaps if you want to do some reporting about how things were a year ago vs. how they are now or the like. But I think the frequency of such a use case would be rare enough that the general performance issues out-rank it. What we're talking about here is essentially table sharding. And I think that even a small installation will find the performance degradation of having an order magnitude more rows in a table to be unacceptable. Keep in mind that we wouldn't need a duplicate for *every* table. the contact tables, and custom field tables would probably suffice.

A one second granularity is only good enough if the system can gracefully handle cases where multiple changes happen within the same second because it will happen often enough.

I'd recommend that the initial release only focus on the back-end and allow the ability to turn the feature off. Once the back-end is in production for a release cycle a UI could be constructed to show revisions and perhaps allow rollbacks.