[dev] History of share changes

Jan Schneider jan at horde.org
Thu Aug 13 21:54:04 UTC 2009


Zitat von Chuck Hagenbuch <chuck at horde.org>:

> 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.

Out of curiosity: what would we need this for? For displaying in the  
UI this is not sufficient, as long as we still want to display the  
last editor like we do now. Which is a good idea.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.horde.org/archives/dev/attachments/20090813/c03dd233/attachment.bin>


More information about the dev mailing list