SQL FK и предварительная проверка на существование

Question

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

В .NET мы всегда стараемся избегать кодирования исключений в том смысле, что не используются повышенные исключения для управления потоком кода.Это означает, что мы пытаемся обнаружить потенциальные ошибки раньше времени выполнения.

В SQL я вижу две противоположные точки

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

2) Предварительная проверка позволяет разработчику вызывать более информативные исключения в вызывающем приложении.Вместо того, чтобы получать общее «нарушение внешнего ключа», можно возвращать разные коды ошибок для каждой проверки, которую необходимо выполнить.

Что вы думаете?

Answer 1

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

Answer 2

Не проверять раньше:

• Механизм БД все равно проверит на INSERT (у вас есть 2 чтения индекса, а не одно)
• он не будет масштабироваться без подсказок блокировки или семафоров, которые уменьшают параллелизм и производительность (2-й перекрывающийся параллельный вызов может пропустить EXISTS до того, как первый вызов выполнит INSERT)

Что вы можете сделать, это обернуть INSERT в собственный TRY / CATCH и проигнорировать ошибку xxxx (нарушение внешнего ключа, извините, не знаю этого). Я упоминал об этом раньше (для уникальных ключей, ошибка 2627)

• Вставить строку, только если ее там еще нет
• Выбор / вставка версии Upsert: есть ли шаблон проектирования для высокого параллелизма?
• SQL Server 2008: ВСТАВИТЬ, если нет, сохранить уникальный столбец

Это очень хорошо масштабируется до больших объемов.

Answer 3

Я не вижу преимущества предварительной проверки на нарушения FK.

Если вам нужны более информативные заявления об ошибках, вы можете просто обернуть вставку в блок try-catch и вернуть пользовательские сообщения об ошибках поэтот момент.Таким образом, вы выполняете дополнительные запросы только при сбое, а не каждый раз.