Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Проектирование БД Новый топик    Ответить
 Отслеживание изменений. Вручную или (Change Data Capture или Change Tracking)?  [new]
mDanilov
Member

Откуда: Екатеринбург
Сообщений: 10
Впервые столкнулся с задачей. Нужен авторитетный совет, вручную делать логирование изменений, или воспользоваться CDC или CT.
Склоняюсь к ручному. Подробности:

+ Магазины

create table Shop
(
[Id] int identity(0,1) primary key,
[Name] varchar(250) not null,
Address varchar(250) not null,
Unused bit not null
)


+ Товары в розничном магазине

create table Item
(
[Id] int identity(0,1) primary key,
GroupId int not null,
[Name] varchar(100) not null,
NameCassa varchar(50) not null,
NamePriceList varchar(50) not null,
NameLabel varchar(50) not null,
Volume decimal(6,3) not null,
LifeTime int not null,
composition varchar(400) not null
)


+ Допуски и наценки товаров на магазинах

create table Item
(
ShopId int, 
ItemId int,
TradePermis bit not null,
Price real not null

constraint pkIIdShId primary key (ShopId, ItemId) ,
constraint fkShId foreign key (ShopId) REFERENCES Shop(Id),
constraint fkIId foreign key (ItemId) REFERENCES Item(Id)
)



Нужно логировать изменения атрибутов таблиц Item (строк > 210к)и ShopItem ( > 210к * кол-во магазинов(Shop) ).
Каждый день в таблицах Item и ShopItem примерно по 1.5к изменений в каждой.
Задача состоит в том, чтобы высылать в магазины из головного офиса не всю таблицу, а только изменения за день.

Прочитал про CT и CDC по диагонале на хабре и линки с них.
В Change Tracking не хранится время изменения. И значение измененных атрибутов, только версии изменений, операции и первичные ключи.
В Change Data Capture, как я понял, если меняется значение одного атрибута в строке, то логируется все атрибуты. А в оригинальной таблице Item их много(=21).

Ручное решение:
+ Таблица, логирующая изменения

create table sysColumns_log
(
Id bigint identity(0,1)  primary key,
pkId smallint not null,     --object_id из sys.objects
column_id int smallint,  --column_id из sys.columns 
pkValue xml not null,   --значение первичного ключа.
ValueNew sql_variant not null,  --новое логируемое значение атрибута,
Time datetime,      --время изменения
OpId int               --операция (добавить/удалить, изменить, отправить данные)
)



pkValue имеет тип xml ибо первичный ключ может быть составным. Я специально вначале привёл в пример 2 таблицы, где у таблицы Item первичный ключ по полю Id, а ShopItem по ShopId и ItemId,
т.е. значения будут примерно следующие:
Для Item:
<Id>1</Id>,
<Id>2</Id>,
<Id>999</Id>
Для ShopItem:
<ShopId>1</ShopId><ItemId>2</ItemId>,
<ShopId>1</ShopId><ItemId>999</ItemId>

Если что: я помню, что sys.column_id уникален только для одного sys.object_id. Но у меня в таблице есть object_id первичного ключа таблицы, по нему можно найти object_id таблицы, которой принадлежит колонка


Собственно хотел бы знать мнение гуру. Больше читать, про CT, CDC или ручное решение приемлемо? Если RTFM, то что именно
8 июн 17, 15:36    [20550488]     Ответить | Цитировать Сообщить модератору
 Re: Отслеживание изменений. Вручную или (Change Data Capture или Change Tracking)?  [new]
mDanilov
Member

Откуда: Екатеринбург
Сообщений: 10
mDanilov,
Поправка:
1) Описка: таблицу sysColumn_log правильнее назвать ObjectChanging_log чтобы никто не запутался
2) Не пояснил: pkId - это object_id первичного ключа из sys.object. По нему уже понятно по какой таблице идет логирование
8 июн 17, 15:43    [20550513]     Ответить | Цитировать Сообщить модератору
 Re: Отслеживание изменений. Вручную или (Change Data Capture или Change Tracking)?  [new]
LSV
Member

Откуда: Киев
Сообщений: 30130
Я бы не делал одну таблицу для логгирования:
1. Неудобно ни писать ни читать.
2. Для логгирования 1 записи таблицы с многими полями нужно создавать много записей в лог.

Ваши аппетиты на логгирование непременно вырастут. И этой таблицы все равно не хватит.

Делайте отдельные лог-таблицы подобной оригиналу структуры.
Можно вообще объединить ф-цию хранения инфы и логирования просто добавив дату в осн. таблицу. :)

Зачитывать оттуда ф-цией, кот. достанет нужное значение на нужную дату.
8 июн 17, 15:58    [20550594]     Ответить | Цитировать Сообщить модератору
 Re: Отслеживание изменений. Вручную или (Change Data Capture или Change Tracking)?  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 4666
mDanilov
Каждый день в таблицах Item и ShopItem примерно по 1.5к изменений в каждой.
Задача состоит в том, чтобы высылать в магазины из головного офиса не всю таблицу, а только изменения за день.
вам нужна вся история изменений за день или только самое последнее изменение?
8 июн 17, 22:06    [20551569]     Ответить | Цитировать Сообщить модератору
 Re: Отслеживание изменений. Вручную или (Change Data Capture или Change Tracking)?  [new]
mDanilov
Member

Откуда: Екатеринбург
Сообщений: 10
Дедушка,
Последнее
9 июн 17, 09:10    [20551960]     Ответить | Цитировать Сообщить модератору
 Re: Отслеживание изменений. Вручную или (Change Data Capture или Change Tracking)?  [new]
mDanilov
Member

Откуда: Екатеринбург
Сообщений: 10
mDanilov,
LSV правильно сказал, что в перспективе аппетиты логирования вырастут, и изменения из других таблиц тоже придётся логировать.
Именно поэтому я и стараюсь хранить логи в одной таблице, чтобы новые не создавать. Максимум - новые процедуры и триггеры

Основной то вопрос у меня все-таки такой: Я правильно понял, что для моей задачи CT и CDC не подходит? И надо вручную делать?
9 июн 17, 09:16    [20551972]     Ответить | Цитировать Сообщить модератору
 Re: Отслеживание изменений. Вручную или (Change Data Capture или Change Tracking)?  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3308
mDanilov
Дедушка,
Последнее

для твоей задачи хватит простого поля "last_update_datetime" в каждой таблице обновляемого триггером.
И раз в сутки пересылаешь то, что изменилось за день. (Тебе же не нужна вся история изменений)
Всё, профит.
23 июн 17, 17:20    [20586771]     Ответить | Цитировать Сообщить модератору
Все форумы / Проектирование БД Ответить