Могу ли я проверить наличие ограничений перед удалением в SQL Server?

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

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

Это возможно?

10.12.2008 17:42:24
5 ОТВЕТОВ
РЕШЕНИЕ
If Exists ( Select * From OtherTable
            Where OtherTableFKColumn = MainTablePrimaryKey) 
   Begin
       Rollback Transaction
       RaisError('Violating FK Constraint in Table [OtherTable]', 16, 1)
   End
1
10.12.2008 17:45:20
Хорошо, это правильный подход, но что если кто-то позже добавит другие таблицы, которые связаны с этой таблицей. Этот код должен быть изменен.
Drejc 10.12.2008 17:54:23
о, вам нужно одно из них для каждой таблицы, имеющей FK для основной таблицы ... Если этот список изменится, то да, этот код придется изменить, чтобы добавить дополнительный оператор для этой дополнительной таблицы.
Charles Bretana 10.12.2008 18:07:53

Кроме проверки COUNT(*)каждой связанной таблицы? Я так не думаю.

1
10.12.2008 17:46:13

Одной из уродливых попыток было бы попытаться УДАЛИТЬ в транзакции, а затем вызвать ROLLBACK, если она прошла успешно. Но это грязно на мой вкус.

0
11.12.2008 11:51:40
Разве он не сказал, что хочет сделать проверку до УДАЛЕНИЯ?
FelixM 27.11.2009 21:02:18

Это вопрос, который на первый взгляд выглядит хорошо, но имеет значение.

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

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

Теперь, действительно ли исключение, которое вы получаете, кажется таким дорогим после этого испытания?

0
11.12.2008 12:04:32
Основная проблема заключается в том, что дизайн базы данных не идеально подходит для данной задачи. Но факт заключается в том, что базу данных нельзя изменить, поэтому мне нужно найти обходной путь для проблемы со зрачком. Плюс я не могу получить данные схемы (мастер база данных). Так что мне просто интересно, какие разные идеи появятся
Drejc 11.12.2008 12:20:41

Я не думаю, что это хорошая идея, чтобы попытаться сделать что-то подобное, потому что это означает, что каждый внешний ключ должен проверяться дважды: один раз вами заранее, а затем снова сервером, когда вы выполняете свой SQL. Влияние на производительность может быть серьезным.

Однако, если вы настроены на это, наиболее общий способ заключается в использовании словаря данных базы данных. Я не знаком со словарем данных SQL Server, но другие реляционные базы данных хранят все свои метаданные в таблицах базы данных, к которым можно обращаться. Вы можете найти все внешние ключи, которые ссылаются на вашу таблицу, и динамически создавать запросы, которые ищут зависимые строки.

0
27.11.2009 18:18:11