ASCRUSавтортак я и сделал..,но есть одно НО.Эта прокси таблица в базе Б(в которой внешние ключи даже определить нельзя) в одном из приложений участвует в запросе многотабличном причём в этом запросе оптимизатор по ходу требует чтобы она полностью была загружена чтобы выполнился запрос..вообщем и запрос там сложный с 2 внешними объединениями.Поэтому уже работающий вариант с прокси таблицей отпадает,ибо тупит сильно((( отрабатывает секунд 14-20(((
А Вы не задумывались над таким вариантом, чтобы не насильно гнать все записи из A в Б, а перегнать просто недостающие записи в Б из А, произведя проверку во время выполнения запроса ? ;)
То есть:
1. В А есть таблица
2. В Б есть прокси таблица на таблицу в А
3. В Б есть таблица, аналогичная А
Перед выполнением запроса в Б, теперь достаточно сделать проверку и вставку недостающих записей:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
SELECT max(id) INTO @max_b FROM b.table;
SELECT max(id) INTO @max_a FROM a.proxy_table WITH (REPEATABLEREAD);
IF @max_b < @max_a THEN
INSERT INTO b.table
SELECT * FROM a.proxy_table WHERE id BETWEEN @max_b AND @max_a;
END IF;
COMMIT;
,,, Дальше сам запрос ...
Таким образом сразу убивается много зайцев:
1. База А не напрягается передачей изменений, они передаются по требованию базы Б
2. База А не рискует откатить транзакцию из за того, что не нашла базу Б
3. База Б держит локальную копию данных и всегда уверена в их актуальности, которая гарантируется перед выполнением запроса
4. Данные в базе Б гарантируют целостность, но не мешают писателям базы А писать новые записи
В роли ключа id подходит числовой primary key или timestamp поле.
Согласен!Вариант хорош.А что же будет с актуальностью в таблице Б если в таблицу А будет произведён не Insert а Delete or Update???
