[dev] History of share changes

[Chuck Hagenbuch]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Chuck Hagenbuch <chuck at horde.org>:
>
>> 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.
>
> For simple information that's really required together with the  
> entities, like the modification date, this might be doable. But for  
> anything more complex like what's done in History now (who did what  
> and when), I'd vote against duplication.

Agreed. I've been thinking just create and modify datetimes.

-chuck