I have a (SQL Server) database where I'm tracking changes on a table; the requirement from the customer is to be able to see the "picture" of any point back in time, specifying the requested date.
What I have done so far is to implement a HistoryTable
, following the idea of Log trigger, with database triggers to store historical data.
Now, the requirement changed, and I need to add a many-to-many (n-m) relationship to the original table. Of course, the linked data set (n-m relationship) should be "versioned" as well, changing over time as the original table.
My first idea is to refer the n-m relation with a "fake ID" in the main table, that is: a normal (int) field, and not the primary key (which is not changing over time). In this way, I could change that ID over time, for instance:
Version 1:
Version 1
ID RelID Data
5 5 Version 1
Version 2
ID RelID Data
5 5 Version 2
Version 3
ID RelID Data
5 6 Version 3
In this example, the n-m relation did not change between version 1 and 2, but changed in version 3.
This is fine, but my questions are:
- Whenever the n-m relation version changes, how can I get a new RelID that is unique in the table?
- Another option: can I refer the n-m relation to both the ID and the RelID (that is unique for sure)?
- Is there any smarter solutions than mine?
Thank you in advance for any help