DB2 поддерживает синхронизацию n столбцов между двумя таблицами

Question

У меня есть две таблицы (на самом деле наборы таблиц), которые, возможно, необходимо поддерживать синхронизированными (первый набор таблиц мне нужно, чтобы все данные были реплицированы во второй набор, где эти данные будут подмножеством).

Если почему имеет значение (возможно, потому что это явно не очень хорошая форма с реплицированными данными), см. (В самой нижней части этого другого вопроса в разделе ' PS '): Триггер обновления и вставки DB2 ссылается на множество полей, которые я могу использовать *, чтобы сократить их (в iSeries, но это может не иметь значения)

Для этого я помещаю триггеры вставки, обновления и удаления в то, что я назову «первичным набором», который будет вставлять, обновлять и удалять записи в «реплицируемом наборе».

Мой вопрос заключается в том, что если я хочу теперь синхронизировать реплицированный набор с основным набором? Я смотрю на документацию прямо сейчас, чтобы увидеть лучший способ сделать это. Я не хочу, чтобы триггер вставки пытался вставить в то, во что когда-либо была первоначально вставлена ​​таблица, так как это, как я ожидаю, вызовет ошибку, которая будет возвращена программе, выполняющей вставку, если в триггере нет пути для выкинуть такую ​​отчетность? Лучший способ в настоящее время выглядит как проверка, существует ли запись перед удалением, то же самое для вставки.

Тогда возникает проблема повторения в триггере обновления, мне было интересно, есть ли более элегантное решение, чем проверка того, что значения одинаковы, а затем не обновление?

Первичный набор не может быть изменен каким-либо образом (за исключением триггеров, которые никак не изменяют ввод / вывод из таблицы), в то время как схема реплицируемого набора является полностью гибкой.

Оптимизация для ленивости (возможно, я собираюсь автоматизировать создание этих триггеров, но если у вас есть предложения о том, как сохранить их компактность, это ускорит мое развитие).

Система не интенсивно используется, у нее тонус свободных ресурсов ... нет необходимости быть осторожным с памятью, обработкой и дисковым пространством.

Answer 1

Вместо использования реплицированных таблиц вам будет гораздо лучше использовать представления.Это позволит вам полностью отделить доступ к вашей базе данных от вашего базового дизайна базы данных.С комбинацией обновляемых / удаляемых представлений и триггеров «вместо», вы должны быть в состоянии делать вещи хорошо.Помните, что это рекомендуемая установка, даже если вы используете только SQL (и на любом языке), поскольку она позволяет отделить дизайн программы от дизайна базы данных.Тот факт, что он позволяет отделить PF от iSeries, является лишь бонусом.

Хорошая новость - вам пока не нужно все переключать, чтобы использовать SQL - iSeries фактически настроен так, чтобы вы могли получить доступ к SQLобъекты (такие как представления и триггеры), как если бы это был физический файл с собственным доступом к файлу RPG.
Плохие новости - в отличие от логических файлов, представления не могут быть упорядочены.Если вы используете многократный доступ к ключу через логические файлы, ваши усилия могут быть сложными ... Я не пытался получить доступ к индексу SQL с помощью операции CHAIN, чтобы проверить, дает ли он мне доступ к остальной части записи, поэтомуЯ понятия не имею, сработает ли это.

РЕДАКТИРОВАТЬ:

Наконец-то дошли до тестирования этого.Оказывается, что доступ к индексам для их упорядочения (как для логического файла с ключами) действительно предоставит доступ к остальной части записи.Не уверен, поможет ли это вам или нет.

Answer 2

Я публикую это как ответ, чтобы сделать то, что я собираюсь сделать в этот момент, очень ясно.Любое улучшение будет принято в качестве ответа.

Реализация после триггеров для вставки, обновления, удаления в обеих таблицах.Таким образом, референтные ограничения будут срабатывать и точно сообщать пользователю.

Триггеры удаления и вставки должны проверить, существует ли уже запись, чтобы предотвратить создание ошибки, которая будет отправлена ​​обратно пользователю.

Триггер обновления должен проверить, можно ли обновить запись перед применениемобновление для предотвращения рекурсии.

Это форма триггеров, которые я намерен использовать:

Триггер обновления, который будет синхронизировать две таблицы (применительно к каждой таблице), обновлять только в том случае, если записьнесинхронизировано:

create trigger tableUpdate after update on fromSchema/tName  
 referencing new as n                                               
 for each row mode db2sql                                           
 begin atomic  
    update toSchema/tName target set (<-- all target.columns = n.columns -->)
         where <-- all target.column's != n.column's -->;   
end

Вставить триггер, который будет синхронизировать две таблицы (применительно к каждой таблице), только вставки, если запись не существует:

create trigger tableInsert after insert on fromSchema/tName  
 referencing new as n                                               
 for each row mode db2sql                                           
 begin atomic  
    insert into toSchema/tName select                      
     t1.*                                                  
    from fromSchema/tName as t1 left join toSchema/tName as t2
    on <-- t1.pkColumn's = t2.pkColumn's -->                                   
    where <-- t2.pkColum's IS NULL -->   
end

Удалить триггер, который будет синхронизироватьсядве таблицы (применительно к каждой таблице), удаляет только там, где существует запись:

create trigger utbachDelete after delete on fromSchema/tName  
 referencing old as o                                               
 for each row mode db2sql                                           
 begin atomic   
    delete from toSchema/tName target where <-- target.keyValues = o.keyValues -->;                                                           
end