12 votesTony Donley shared this idea ·
Upvotes: 2<=-=Oct 20 2017 2:44AM=-=>
Thank you for taking the time to post this proposal!
Can you share more details about your use case, that describe joins required to obtain current values and also how partial temporal tables would make your development process faster?
Regarding storage used for history data, usage of clustered columnstore index for history table reduces storage size significantly.
Thanks,<=-=Oct 20 2017 8:07AM=-=>
Thank you for your attention. I have updated the description to make it clear what the present options are and the drawback of each: unnecessary writes/storage, unnecessary joins, or requiring the developer to implement partial versioning themself for each such table.
An error occurred while saving the commentTony Donley commented
I don't want to "ignore index options". I want them carefully considered and explicitly specified in source control so they are deployed consistently in every environment.
When the only difference is the compression setting, I don't expect the engine to generate a long table rebuild. I expect and ALTER INDEX...REBUILD statement with the appropriate options.
I would also love to see the SORT_IN_TEMPDB option honored.