SQL Server — временная таблица — затраты на хранение

есть ли какая-либо информация в сети, где я могу проверить, насколько высока стоимость хранения для функции темпоральных таблиц?

Будет ли сервер создавать полную копию измененной строки/кортежа? Или сервер будет использовать ссылку/ссылки на исходные значения главной таблицы, которые не были изменены?

Например. У меня есть строка с 10 столбцами = хранилище 100 КБ. Я меняю одно значение этой строки, сколько раз. У меня есть строки в исторической таблице после этих изменений. Является ли стоимость хранения для основной и исторической таблицы ~ 300 КБ?

Спасибо за каждую подсказку!

Рагард


sql-server temporal-tables
person user1481065    schedule 09.02.2018    source источник
comment
Это не исчерпывающее руководство по хранению, но есть как минимум одно предупреждение о хранении здесь ... Несмотря на то, что темпоральные таблицы поддерживают типы данных BLOB... они требуют значительных затрат на хранение... следует соблюдать осторожность при использовании этих типов данных< /я>   -  person ta.speot.is    schedule 09.02.2018
comment
Если кто-то дает ответ, и это слишком дорого для вас, какие альтернативы вы рассматриваете? Есть ли причина, по которой вы не можете проводить эксперименты и измерять эти вещи самостоятельно?   -  person Damien_The_Unbeliever    schedule 09.02.2018
comment
В настоящее время я использую устаревшее решение для самостоятельной сборки из SQL Server 2005, где я копирую только значение столбца изменений и имя столбца в специальной таблице. Я планирую заменить эту устаревшую конструкцию функцией темпоральной таблицы.   -  person user1481065    schedule 09.02.2018

Ответы (1)


arrow_upward
0
arrow_downward

Будет ли сервер создавать полную копию измененной строки/кортежа? Или сервер будет использовать ссылку/ссылки на исходные значения главной таблицы, которые не были изменены?

Вот ссылка на книгу Pro SQL Server Internals Дмитрия Короткевича, которая отвечает на ваш вопрос. :

Короче говоря, каждая темпоральная таблица состоит из двух таблиц — текущей таблицы с текущими данными и таблицы истории, в которой хранятся старые версии строк. Каждый раз, когда вы изменяете или удаляете данные в текущей таблице, SQL Server добавляет исходную версию этих строк в таблицу истории.

Текущая таблица всегда должна иметь определенный primary key. Более того, и текущие, и исторические таблицы должны иметь два столбца datetime2, называемых столбцами периода, которые указывают время жизни строки. SQL Server автоматически заполняет эти столбцы в зависимости от времени начала транзакции при создании новых версий строк. Когда строка была изменена несколько раз в одной транзакции, SQL Server не сохраняет незафиксированные версии промежуточных строк в таблице истории.

SQL Server помещает таблицы истории в файловую группу по умолчанию, создавая неуникальные кластеризованные индексы для двух столбцов datetime2, которые управляют временем жизни строки. Он не создает никаких других индексов в таблице.

Как в Enterprise, так и в Developer Edition, таблицы истории используют страницу compression по умолчанию.

Так что это не

ссылка/ссылки на исходные значения главной таблицы

Предыдущая версия строки просто копируется как есть в историческую таблицу при каждой модификации.

person sepupic    schedule 09.02.2018