Возник вопрос по скорости работы решений и наличию дедлоков.
И так имеем:
MS SQL 2008
TableA — примерно 6м записей
Log — примерно 40м записей
данные в TableA редактируются через хранимки. После каждого редактирования создается запись в логе.
Нам потребовалось немного денормализовать структуру и иметь в TableA id последней операции.
Немного по условиям функционирования:
За один раз в TableA может меняться до нескольких тысяч записей. Максимум что я видел 80к записей, но в среднем 10-1000
Теперь варианты, что с этим предполагается делать:
Вариант 1
в TableA добавляется колонка для хранения id
в хранимке, добавлябщей запись в лог, мы апдейтим TableA. Так как порядок запросов обратный(весь код сначала делает изменение а потом пишет в лог) мы предварительно берем лок на нужный кусок таблицы, после чего работаем с логом и идем апдейтить таблицу. Так мы поидее должны избежать дэдлоков
Коллега, с большим стажем работы с БД, утверждает что из-за постоянных апдейтов будет тормозить. Так как TableA используется много где, на апдейтах она будет запираться, и все будет жутко тормозить.
Вариант 2
Аналогичен первому варианту но для хранения используется дополнительная таблица. Явный минус, что требуется джоин для получения данных
Вариант 3
По хранению аналогичен второму. Но обновлять таблицу, предполагается, из брокера
