[dev] History of share changes

[Chuck Hagenbuch]

Quoting Jan Schneider <jan at horde.org>:

>>>> If you are still worried about this after all that, create both a  
>>>> history table and a 'current' table. The history table will  
>>>> likely not be accessed as much as the current dataset, so your  
>>>> 'current' table will be smaller in size, and you can optimize for  
>>>> specific access patterns.
>>>
>>> Any more opinions about this?
>>
>> I've been thinking that we should put created and modified fields  
>> back into most of our entity tables. That would address a lot of  
>> the problems here for speed and also make History not necessary for  
>> many uses. The only thing it doesn't address is prior revisions  
>> (which history doesn't really address either) and tracking deleted  
>> items (which could either still use history, or use a simplified  
>> system).
>
> I don't see any problem with the history system per se. I doubt that  
> having the date attributes with the original data will have much if  
> any performance improvement over a separate table.
> Having a central place for all history data is much better  
> maintenance-wise too, we would not only need a place to track  
> deleted data, but we also have history that's not related to  
> anything stored in our database, like message history.

That's true, and all good reasons, and I made the darn History API in  
the first place so I should be partial to it. However I'd also had  
trouble when trying to deal *just* with an app's data, and needing to  
pull in history also. What do you think of storing them in both  
places? Horribly non-normalized I know.

-chuck