А в наборе данных ведь Вам придется сравнивать и данные по этой 'ссылке'. А по Вашей сверке можно только узнать наличие объектов, но не различия реквизитов.
1.Есть два одинаковых произвольных запроса с уникальной сортировкой (перечень полей, в том числе ссылки).
2.Один из базы источник (1С), другой из базы приемник (не 1С).
3.Открыли запросы.
4 Сравнили значения полей сортировки.
5.Если они равны, сравниваются все остальные поля запроса источника с полями запроса. Если они не равны, то выполняется изменение этой записи в базе приемнике. После чего переход на следующую запись и в запросе из базы источник и в запросе из базы приемник. На шаг 4.
6. Если поля сортировки из источника больше, то надо удалить запись в базе приемнике и в запросе из нее перейти на следующую запись. На шаг 4.
7. Если поля сортировки из источника меньше, то надо вставить запись из источника в базу приемник. А в запросе из базы источник перейти на следующую запись. На шаг 4.
И так крутимся до момента, пока в обоих запросов не будет достигнут конец.
Когда конца достигает лишь один из запросов, непосредственно сравнение полей сортировки (шаг 4) не далется, алгоритм идет во ветке, как будто поля сортировки закончившегося запроса имеют большие значения чем не закончившегося.
Это упрощенный алгоритм используемой нами для синхронизации. Его сложность ~R*F, где R кол-во записей, а F количество полей. Реальный алгоритм, несколько сложней тем, что он допускает не уникальную сортировку наборов.
Программист Может правильнее в обоих базах записывать изменные или новые обьекты и потом уже только ими обмениваться?
Здесь речь идет об одностороннем обмене, то есть запись только в базу приемник. Но это пустяк.
Важно то, что репликация (синхронизация) по приращениям, которую Вы предлагаете, конечно намного эффективнее, чем полная перечитка (описанная выше).
Но она применима лишь в варианте, когда производиться передача в базу приемник таблиц, в том виде и в том составе, в котором они есть в базе источнике. Для этого в базе источнике обеспечивается логирование (журнал операций) этих таблиц, с помощью которого из нее вычитываются только новые и измененные записи. Эта схема мне известна, но она мне не подходит.
Так как в моем случае синхронизации подвергаются результаты произвольного (написанного пользователем)
сложного запроса, в котором потенциально есть join, в том числе (если это есть в 1с) с хранимыми процедурами и
всякие другие SQL штуки. Это запрос некая выжимка нужных пользователю данных.
Результат данного и любого запроса - это таблица, и вот эта таблица
заливается в базу приемник, а потом синхронизируется, описанным выше алгоритмом.
То есть на самом деле запросы не одинаковы по составу, из 1с берется сложный запрос. Например
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
ВЫБРАТЬ
Продажи.Номенклатура КАК ГУИД,
Продажи.Количество,
Продажи.Стоимость,
ПартииТоваровНаСкладах.Стоимость КАК Стоимость1,
Продажи.Номенклатура.НоменклатурнаяГруппа,
Продажи.Номенклатура.Код,
Номенклатура1.НоменклатурнаяГруппа,
Номенклатура1.Ссылка,
Номенклатура1.Наименование,
Продажи.Регистратор,
Продажи.НомерСтроки
ИЗ
РегистрНакопления.Продажи КАК Продажи
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ПартииТоваровНаСкладах КАК ПартииТоваровНаСкладах
ПО Продажи.Регистратор = ПартииТоваровНаСкладах.Регистратор
И Продажи.НомерСтроки = ПартииТоваровНаСкладах.НомерСтроки
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура КАК Номенклатура1
ПО Продажи.Номенклатура = Номенклатура1.Ссылка
Order by Продажи.Регистратор,Продажи.НомерСтроки
А в базе приемнике этому запросу ставиться в соответствие таблица. Наприимер с именем Запрос1.
Состав полей - все поля из запроса 1С.
То есть для базы приемник открывается запрос
1.
2.
3.
select *
from Запрос1
order by Регистратор, НомерСтроки
А дальше происходит то, что описано выше. Программа бежит по обоим запросам и
выдает при необходимости в базу приемник команды update\insert\delete.
Если бы мне в базе приемнике нужны были бы по отдельности таблицы
РегистрНакопления.Продажи, РегистрНакопления.ПартииТоваровНаСкладах, Справочник.Номенклатура и т.д.
то конечно нужно \ можно использовать репликацию по приращениям. Но они мне там не нужны, мне там нужен результат вот такого запроса. Передавать по приращениям отдельные таблицы, а потом все равно открывать запрос (уже только в базе примник), смысла нет. Да на 1 запрос будет меньше, но и репликация по приращением, в общем случае, не бесплатное удовольствие.
Хотя, если весь проект, связанный с этой темой, взлетит, то может быть для 1с или других системе обеспечивающих репликацию по приращениям может быть и имеет смысл сделать опционально. Так как Вы уже второй программист 1с, который советует мне это сделать.
Но пока хватит того что есть с головой.
Приводить пример терабайтной базы, у которой изменилась 1 запись, надо?
Та нет, во общем то понятно, что такое бывает. На это случай, пока, есть другие инструменты.
Сюда кто то дочитал? :)
