|
|
|
лог для вьюхи
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток! Вопрос вот в чем - есть вьюха, которая собирает данные из нескольких разных баз и серверов (разные версии MS SQL, не оракл), как проще всего реализовать лог на изменение результирующего набора данных (добавилась запись/ушла/поменялось неключевое поле)? Понятно, сходу джобом выгружать в табличку по дате времени и сравнивать с предыдущим состоянием. Более элегантного решения нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2021, 16:23 |
|
||
|
лог для вьюхи
|
|||
|---|---|---|---|
|
#18+
Зависит от того, есть ли возможность вносить изменение в "нескольких разных баз и серверов" Если все плохо, возможности вносить изменения в структуру нет, и данные таблицы не содержат какой-либо информации о дате обновления, то в любом случае придется вычитывать все данные. Можно попробовать поиграться с CHECKSUM_AGG с группировкой до диапазонам ключей, чтобы не тащить все данные по сети, а отсекать только диапазоны с изменениями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2021, 16:31 |
|
||
|
лог для вьюхи
|
|||
|---|---|---|---|
|
#18+
denis_viktorovich, вьюха это только запрос, что вы делаете с его результатами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2021, 17:11 |
|
||
|
лог для вьюхи
|
|||
|---|---|---|---|
|
#18+
denis_viktorovich, вариант навешать триггеры на все входящие в view таблицы рассматривается? ну или CDC на них? а если есть доступ только в этой view, а к источникам-таблицам на удалённых серверах неть, то "не элегантный вариант" самый элегантный ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2021, 17:35 |
|
||
|
лог для вьюхи
|
|||
|---|---|---|---|
|
#18+
Собственно, а зачем? Что вы хотите получить в итоге? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2021, 17:36 |
|
||
|
лог для вьюхи
|
|||
|---|---|---|---|
|
#18+
uaggster Собственно, а зачем? Что вы хотите получить в итоге? Ваши специалисты еще не в курсе, что логи можно править в своих интересах? Тогда мы идём к Вам! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2021, 17:39 |
|
||
|
лог для вьюхи
|
|||
|---|---|---|---|
|
#18+
denis_viktorovich Более элегантного решения нет?Если запись добавилась/ушла то ничего элегантного нет. Тупо в лоб. Самое сложное поймать изменение неключегого поля. Сравнивать все поля со всеми полями (тем более индексировать все поля) накладно. Можно или добавить rowversion на таблицу источник, или считать хэш от всех полей . А вот этот вот хэш/rowversion можно индексировать и/или исключать по CHECKSUM_AGG И да, в итоге будет не вьюха, а честная таблица на приемнике. Опять же, если можно трогать источник то лучше поигратся с CDC/репликацией ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2021, 18:41 |
|
||
|
лог для вьюхи
|
|||
|---|---|---|---|
|
#18+
SERG1257 ..Самое сложное поймать изменение неключегого поля. Сравнивать все поля со всеми полями (тем более индексировать все поля) накладно.. ну вы, блин, даёте... вьюха с разных серверов, какое тут не "накладно" Код: sql 1. 2. 3. 4. В получателе дописать поле с датой-временем добавления записи, которое исключить при except. Можно ограничить глубину поиска, дабы не очень сильно грузить инфраструктуру. И так раз в минуту. После чего по ключикам (которые в новой табличке перестанут быть pk) можно будет будет посмотреть всю историю изменения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2021, 20:02 |
|
||
|
лог для вьюхи
|
|||
|---|---|---|---|
|
#18+
denis_viktorovich, чтобы узнать - произошли ли изменения в данных, не выгружая сами данные, необходимо получать информацию об изменениях из источников этих данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2021, 20:31 |
|
||
|
лог для вьюхи
|
|||
|---|---|---|---|
|
#18+
StarikNavy denis_viktorovich, вьюха это только запрос, что вы делаете с его результатами? Есть скажем объект аля заказ, плановые сроки, даты запуска/выпуска, параметры хранятся в одной системе, данные об изготовлении в другой, данные о контрагенте и контракте в третьей. Версии скуля разные, где то и 2005. И есть задача интеграции с другой системой, и как тут правильно сказали затратность процесса высокая, выгружать все подряд не получится (просто не будет хватать ночи со временем). Брать им надо только измененные объекты и желательно понимать, что изменилось (дабы не все обновлять, ну и хранить причину изменений). Итого, как я понял - или логи на все входящие таблицы или периодическая выгрузка в таблицу и уже анализ ее содержимого. И наверное в данном случае применимее второе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2021, 06:25 |
|
||
|
лог для вьюхи
|
|||
|---|---|---|---|
|
#18+
andy st uaggster Собственно, а зачем? Что вы хотите получить в итоге? Ваши специалисты еще не в курсе, что логи можно править в своих интересах? Тогда мы идём к Вам! хм, не могу представить себе интересанта подобного безобразия. Это как наступать себе на ногу :-). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2021, 06:28 |
|
||
|
лог для вьюхи
|
|||
|---|---|---|---|
|
#18+
denis_viktorovich andy st пропущено... Ваши специалисты еще не в курсе, что логи можно править в своих интересах? Тогда мы идём к Вам! хм, не могу представить себе интересанта подобного безобразия. Это как наступать себе на ногу :-). иногда встречаются люди, которые если могут с помощью update переложить ответственность за косяк на коллегу или просто подставить его, то делают этот update ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2021, 07:26 |
|
||
|
|
start [/forum/topic.php?fid=46&msg=40100801&tid=1684252]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 144ms |
| 0 / 0 |
