репликации строк в каскадных таблицах

Question

У меня есть ситуация, в которой у меня есть несколько связанных / каскадных таблиц. Допустим, все отношения 1-ко-многим каскадно располагаются по таблицам table1, table2, table3, table4 и т. Д. То, что у меня есть, - это строки по умолчанию в таблицах. Они начинаются с 1 записи в таблице 1 и имеют 1 или более связанных записей в других таблицах.

То, что я ищу, это простой способ реплицировать строки и создавать / поддерживать новые первичные ключи для каждого. Под поддержанием я подразумеваю, что table1.ID1 реплицируется, поэтому теперь существует table1.ID2 со всеми остальными столбцами, одинаковыми, только идентификатор изменился.

Кроме того, все связанные с ним строки во всех других таблицах реплицируются, а внешние / первичные ключи указывают на новые.

Таким образом, table2 будет иметь внешний ключ table1.ID2, первичный ключ, скажем, table2.ID #, а остальные столбцы в строке table2 совпадают со строкой, реплицированной в table2.

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

Я не думаю, что это можно сделать, но я надеюсь, что я не прав. Заранее спасибо.

Answer 1

Недавно нам пришлось сделать это для некоторых функций в одном из наших проектов.

В итоге мы сделали это с помощью рекурсивной хранимой процедуры. Каждый звонок требовал двух частей информации:

• Имя таблицы, в которой дублируются записи
• Первичный ключ родительской таблицы дублируемой таблицы

Итак, если у вас есть две таблицы A и B, где A.aid является первичным ключом A, а B.aid ссылается на него, вам потребуется выполнить следующее в псевдокоде:

Function deep_copy (table, parent)
  For each record in table whose parent is parent
    Create a new PK and copy this record
    For each subtable of table
      Call self with parameters (subtable, newPK)

Вы бы позвонили deep_copy на каждую запись А, которую хотите скопировать. Тогда deep_copy будет вызывать себя для записей в B, которые нужно скопировать, и любых других таблиц-братьев в B. Выгода заключается в том, что вам нужна метаинформация, чтобы узнать, что B является дочерним элементом A. Мы случайно сохранили эту метаинформацию уже поэтому мы не должны были делать ничего особенного, чтобы приобрести это.

Что в итоге не является очень большой хранимой процедурой. Если ваши PK - это все столбцы идентификаторов, это значительно облегчает задачу. Хотя это чертовски много разветвляется. Не совсем эффективный алгоритм. Но опять же, это сложная проблема, для которой модели реляционных данных не предназначены для изящного решения.

Answer 2

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