7 ms·
Another technique not discussed is to create an md5 hash of each record and to keep track of added and deleted hashes. The d hash would exist as an additional c
by caerwy 3y ago
Another technique not discussed is to create an md5 hash of each record and to keep track of added and deleted hashes. The d
hash would exist as an additional column on each table being tracked.
- klysm 3y agoI'm not sure I understand what you mean. Where are the hashes tracked?
- caerwy 3y agohere's the article I learned this from. https://www.mssqltips.com/sqlservertip/2543/using-hashbytes-to-track-and-store-historical-changes-for-sql-server-data/ https://www.mssqltips.com/sqlservertip/2543/using-hashbytes-... you'd add a hash column to the table you want to track. this would be used in a data warehouse where you want to track what has changed after a truncate and load. you'd keep additional tables on the side to track added/and delete hashes for a delta copy to downstream application tables.
- agarren 3y agoIf I understand you right, this seems like a very course-grained way to track changes. You can record that a change was made, but not the specific change. It seems like it'd help facilitate something like, say, an etag, but I don't think could get any auditable data using this alone, could you? Keeping track of added/deleted hashes would probably be best handled by a trigger, unless you really want that in your app code, so this seems a lot like an audit trigger, with very little audit data. Have I misunderstood?