Hi Alessandro, We've implemented an approach similar to this for storing and tracking changes to XML documents - because the values we are storing could be large (base 64-encoded binary objects), we decided to have a 'attribute-value' table that would only allow inserts, plus an 'audit-record' table that tracks when/where/who changed the value.
This approach works reasonably well for moderate sized documents (1MB / 100,000 values/changes), but it starts to slow down as the number of records/changes exceed 1,000,000. In Oracle and SQL Server, we implemented a VIEW on the attribute-value/audit-record table to only show the most recent value -- makes it easier/faster to get the latest value. Value history is easily retrieved by selecting all values from the attribute-value table with the same unique attribute-id. We haven't optimized our code for Derby, so haven't tried a similar approach here. Best Regards, Thomas Taylor -----Original Message----- From: Alessandro Bottoni [mailto:[email protected]] Sent: Thursday, July 09, 2009 10:48 AM To: Derby Discussion Subject: Re: How would you implement a record-level versioning system with Derby and Java? Peter Ondru�ka ha scritto: > Actually I would store the history values outside the main table for > performance and storage overhead reasons (history table may have > additional columns, e.g. When-who-etc for auditing information). Peter Yep... This has to be kept into account, actually, and it makes the whole thing a little bit more complicated... Thanks for this suggestion, Peter. -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ Who wants to remember that escape-x-alt-control-left shift-b puts you into super-edit-debug-compile mode? -- (Discussion in comp.os.linux.misc on the intuitiveness of commands, especially Emacs.)
