Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Поддержание консистентности 2х разных структур. Помогите изобрести велосипед!  [new]
uaggster
Member

Откуда:
Сообщений: 867
Коллеги, прошу помощи!

Краткое содержание истории:
1. Имеется некая довольно сложная структура данных. Пара десятков [больших] таблиц, сложные взаимодействия между ними.
2. Имеется более простая структура одна [несколько] таблиц, содержимое которых однозначно определяется данными из сложной, "родительской" структуры.
3. Вообще говоря, содержимое дочерней структуры может быть описано запросом sql (несколькими, т.к. "дочерних" таблиц - несколько), НО, по всему объему данных выборка происходит очень долго, до десятков минут, возможно даже больше.
4. Запрос, формирующий каждую "дочернюю" таблицу - довольно непростой сам по себе, изобилующий всяческими outer apply, запросами преобразующими данные из связанных таблиц "родительской" структуры в xml поля в дочерней таблице и т.д.
В общем, многоэтажно, запутано и нетривиально.
5. Данные родительской и дочерней структур связаны по единому ключу.

Задача - поддерживать "дочернюю" структуру в консистентном с родительской структурой состоянии как можно более оперативно.
Поддерживать, разумеется в одну сторону - от родительской к дочерней.

Т.е. требуется materialized indexed view, но с учетом того, что запрос у нас с преферансом и энтузиастками.

Вопрос КАК???

Пока не придумал ничего лyчше, чем навешать триггеры after insert/update/delete на таблицы родительской структуры, которые писали бы ключи изменившихся данных в некую промежуточную таблицу, а потом вызывать запросы, формирующие дочернюю структуру уже для данных конкретных записей [merge]. Периодически сторонним приложением.
Если изменившихся ключей немного, в пределах нескольких тысяч, то запросы отрабатывают сравнительно быстро, около минуты.

Но вот чего то мне кажется, что я наизобретал велосипедов.
Посоветуйте чего-нибудь!?

MSSQL 2012.
26 июл 14, 14:16    [16360824]     Ответить | Цитировать Сообщить модератору
 Re: Поддержание консистентности 2х разных структур. Помогите изобрести велосипед!  [new]
aleks2
Guest
[quot uaggsterПока не придумал ничего лyчше, чем навешать триггеры after insert/update/delete на таблицы родительской структуры, которые писали бы ключи изменившихся данных в некую промежуточную таблицу, а потом вызывать запросы, Посоветуйте чего-нибудь!?
[/quot]

Откройте для себя timestamp/rowversion (ишо в 2000 было). Сэкономите на триггерах.
26 июл 14, 15:12    [16360905]     Ответить | Цитировать Сообщить модератору
 Re: Поддержание консистентности 2х разных структур. Помогите изобрести велосипед!  [new]
uaggster
Member

Откуда:
Сообщений: 867
aleks2, а поподробнее?

Ну вот изменились у меня данные где то в "листе" в родительской структуре. Я в дочерней должен пересчитать всю ветку, относящуюся к некому ID, на котором данный лист через кучу связей и прочего добра (наряду с кучей других листьев) висит. Дальше как поступать?
26 июл 14, 15:46    [16360954]     Ответить | Цитировать Сообщить модератору
 Re: Поддержание консистентности 2х разных структур. Помогите изобрести велосипед!  [new]
WarAnt
Member

Откуда: Питер
Сообщений: 2421
uaggster
aleks2, а поподробнее?

Ну вот изменились у меня данные где то в "листе" в родительской структуре. Я в дочерней должен пересчитать всю ветку, относящуюся к некому ID, на котором данный лист через кучу связей и прочего добра (наряду с кучей других листьев) висит. Дальше как поступать?


Rowversion в вашем случае это замена связки триггер- некая промежуточная таблица
А вообще на задачу надо смотреть на уровень выше,
Зачем нужна вторая структура?
Что потом происходит с данными второй структуры?
Почему нельзя сразу брать данные из первой структуры?
Чем не устроил alwaysOn с readonly нодой?
26 июл 14, 20:49    [16361663]     Ответить | Цитировать Сообщить модератору
 Re: Поддержание консистентности 2х разных структур. Помогите изобрести велосипед!  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
Зачем Вы делаете деревья на реляционных механизмах. Используйте "деревянные" СУБД.
28 июл 14, 11:50    [16365256]     Ответить | Цитировать Сообщить модератору
 Re: Поддержание консистентности 2х разных структур. Помогите изобрести велосипед!  [new]
uaggster
Member

Откуда:
Сообщений: 867
WarAnt
Зачем нужна вторая структура?

Так исторически сложилось. Это "склад складов" :)
Причем - разнородный по структуре (т.е. разные части поддерживаются разными приложениями)

WarAnt
Что потом происходит с данными второй структуры?

Большей частью ее просматривают / ищут по ней, но есть и генерация по ней неких вторичных данных, которые потом используются первичной структурой. Через файлы. Так исторически сложилось. И этот кусок - вообще неприкосновенен, т.к. частью проходит в офлайне и вообще "вписан в бизнес".

WarAnt
Почему нельзя сразу брать данные из первой структуры?

Потому что вторичная структура [целиком] из первичной - очень долго генерируется. А весь софт заточен на использование именно вторичной структуры.
Сейчас проблема решается простой перегенерацией вторичной структуры по ночам. Но "бизнес" это уже не устраивает.

Это "кусочная автоматизация". Сломать и перестроить в обозримом будущем - не дадут. Да и малореально по затратам. Поэтому на вопрос "почему так" - ответ один "потому что так сложилось".

WarAnt
Чем не устроил alwaysOn с readonly нодой?

Не знаю чем не устроил! Поясни поподробнее :)

Владислав Колосов
Зачем Вы делаете деревья на реляционных механизмах. Используйте "деревянные" СУБД.

Там не деревья. Там дубы :)

Rowversion в вашем случае это замена связки триггер- некая промежуточная таблица

И вот все равно я не понимаю, как мне Rowversion может помочь.

Еще раз. Пусть имеется некий глобальный ID, отвечающий за _логическое_ состояние данных как в основной, так и во вторичной структуре. Если со вторичной структурой всё понятно - это просто первичный ключ в итоговых таблицах, то с первичной - это далеко не так. Это, скажем так, ID записи в главной таблице. Остальные связаны с этой главной таблицей реляционно и не совсем. Если данные в подчиненных таблицах первичной структуры изменятся - это может как повлиять, так и не повлиять на вторичную структуру. Выяснить проще всего - просто перегенерировав все данные вторичной структуры по этому ID. Примерно так.
Поэтому и была задумка - триггеры на значимых таблицах складывают кандидатов на пересчет в отдельную таблицу, а сборщик мусора помечает данные во вторичной структуре как "возможно изменились", а потом - перегенерирует их.
29 июл 14, 15:34    [16371790]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить