Talk:Data Synchronization Project

Single History Table

Has there been any more talk of using a single "history" table for all tables instead of duplicating every single table? The only advantage of having another 30 tables in the db is to be able to foreign key each of the columns to the other tables. However, is that needed? The data in the history table won't be accessed on a routine or necessarily speedy basis, right?

Where "data" would be a serialized version of all of those columns. All domain objects that want to do history keeping in this way would implement "OpenmrsHistory" which demands to have "serialize()" and "hydrate(String data)" methods.

Pros of single history table:

• Less tables
• Less extra hibernate objects
• Easy to implement in a generic way
• Easy use when adding new domain objects (via modules or just to core)

Cons of single history table:

• Slower reading of values in history object
• Not as readable when viewing database directly.

-Ben 13:23, 13 July 2007 (EDT)