2 ms·

Can you give some examples of the problems you've had with them? We use SQL Server's temporal-tables - and while they do introduce some restrictions (e.g. you

Can you give some examples of the problems you've had with them? We use SQL Server's temporal-tables - and while they do introduce some restrictions (e.g. you can't mark a column as "ignored" for temporal changes, and only system-versioning (not application-versioning) is currently supported) the feature has overall been an absolute lifesaver for allowing us to do data-recovery from user-error on a per-record basis - all from within our application or directly in T-SQL; whereas previously we'd need to get do a full mount of a PITR backup which requires a lot of manual steps and can take at least an hour in most cases - and then hope that we got the exact point-in-time correct. Even for its use as an auto-auditing system, it's great: we often get customer complaints about us "losing their data" or that we corrupted their records, when in-fact, we have the historical rows and can see that it was one of their own employees (or family-members...) mucking around. Previously we'd have cheerfly accepted the user's complaint and given them a refund or service-credit because it was too much hassle to dig-up the weeks-old HTTP logs or have anxieties about we having any non-transaction-safe OLTP code running causing corruption that we don't know about :S

hobs 3y ago
Schema changes basically causing heterogeneous representations of data. If you only add columns forever and never change types its fine. Oh, and being able to specify the time a thing happened is sometimes useful (though you don't want everyone doing that of course...) Also double checking the docs because its been 5 years since I have reasonably touched SQL Server - no indexes on historical tables so it gets slow fast, Filetable doesn't work* /nvarchar(max) records bloat you hard core. I find that a log record is much better as a non relational/document type record that is isomorphic to the record so I can schema on read if I need to, and if you want to JSON query that stuff it works fine too. * but nobody uses it anymore

hobs 3y ago

Schema changes basically causing heterogeneous representations of data. If you only add columns forever and never change types its fine. Oh, and being able to specify the time a thing happened is sometimes useful (though you don't want everyone doing that of course...) Also double checking the docs because its been 5 years since I have reasonably touched SQL Server - no indexes on historical tables so it gets slow fast, Filetable doesn't work* /nvarchar(max) records bloat you hard core. I find that a log record is much better as a non relational/document type record that is isomorphic to the record so I can schema on read if I need to, and if you want to JSON query that stuff it works fine too. * but nobody uses it anymore