Объединить первичные ключи - каскадное обновление
Есть ли способ объединить два первичных ключа в один, а затем каскадно обновить все затронутые отношения? Вот сценарий:
Клиенты (idCustomer int PK, Company varchar (50) и т. д.)
Контакты с клиентами (idCustomerContact int PK, idCustomer int FK, Name varchar (50) и т. д.)
CustomerNotes (idCustomerNote int PK, idCustomer int FK, текст примечания и т. д.)
Иногда клиентов нужно объединить в одного. Например, у вас есть клиент с идентификатором 1, а другой - с идентификатором 2. Вы хотите объединить оба, чтобы все, что было 2, теперь равно 1. Я знаю, что могу написать сценарий, который обновляет все затронутые таблицы по очереди. один, но я хотел бы сделать его более перспективным, используя каскадные правила, поэтому мне не нужно обновлять скрипт каждый раз, когда добавляется новое отношение.
Есть идеи?
Что ж, я бы хотел, чтобы один клиент сохранил свой идентификатор, а другой принял этот идентификатор. Я предполагаю, что это также можно назвать заменой, я просто использую слияние в том смысле, что два клиента объединяются в одного.
Ответы 4
Вместо этого рассмотрите возможность использования триггеров. При обновлении клиентов (столбец idCustomer) вы вносите все необходимые изменения (удаление, обновление ...) в связанные таблицы.
Независимо от того, использую ли я триггеры или каскадное обновление для обновления затронутых таблиц, у меня по-прежнему нет возможности выполнить слияние, как описано в вопросе.
Автоматического способа сделать это нет, но у вас есть несколько вариантов: вы можете вручную написать процедуры, или вы можете либо код генерировать слияние на регулярной основе, либо динамически генерировать его во время выполнения. Для этого вы можете использовать INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS и INFORMATION_SCHEMA.KEY_COLUMN_USAGE, а также INFORMATION_SCHEMA.TABLE_CONSTRAINTS и INFORMATION_SCHEMA.COLUMNS and INFORMATION_SCHEMA.TABLES для динамического построения процедуры.
Вы также можете просто заключить всю операцию в транзакцию (в любом случае, это хорошая идея). Последним шагом будет удаление клиента, из которого выполняется слияние, поэтому, если в таблице, которую вы никогда не добавляли, есть RI, и вы пытаетесь выполнить слияние, это не удастся, потому что вы не можете удалить клиента, из которого выполняется слияние, поскольку есть зависимые записи в таблице, которые еще не были добавлены в процедуру слияния.
Похоже, у вас будет две записи для каждой из этих таблиц, у каждой из которых будет один и тот же первичный ключ. Это твое намерение?
Customers
idCustomer Company
1 AT&T
2 Cingular
После слияния станет
Customers
idCustomer Company
1 AT&T
1 Cingular
В любом случае наиболее перспективным решением для будущего было бы написать процедуру. Вы можете передать процедуру обоим клиентам, и он сделает всю работу по обновлению всех таблиц по мере необходимости.
Есть ли более недавнее решение этой проблемы?
У меня такая же проблема, и на данный момент динамическое построение процедур кажется слишком сложным. Вот как это могло бы работать в теории, но я полагаю, что это не так?
В одной транзакции: 1) Временно отключите ограничение первичного ключа для клиентов 2) Обновите первичный идентификатор Cingular до '1', который имеет каскадное правило обновления отношений, заботящееся о детях. 3) Используйте поле вторичного ключа для удаления (только) Cingular 4) Включите ограничение первичного ключа для клиентов
С нетерпением жду чего-то подобного в будущем T-SQL:
УДАЛИТЬ С ОБНОВЛЕНИЕМ idCustomer = 1 ОТ клиентов, ГДЕ idCustomer = 2;
;-)
Вы действительно имеете в виду слияние? Похоже, вы имеете в виду «заменить». Потому что у вас не может быть, например, 2 строк в клиенте с одинаковым идентификатором.