Исправление ошибок внешнего ключа в устаревшей базе данных

Question

Инструменты: SQL2000 / 5/8, .NET 3.5, C #

Я столкнулся с приложением, в котором есть две таблицы. В «коде» таблицы выглядят так:

ТАБЛИЦА 1 (1 —— N) ТАБЛИЦА2

Таким образом, у Table1 (T1) есть Id: IdT1, а у Table2 (T2) есть свой идентификатор (IdT2) и внешний ключ t2.IdT1

Это отношение 1.N является кодом , которое в определенной степени обеспечивается. В БД вообще не было ФК. (Кто бы ни придумал это, он не добавил ни ограничений, ни чего-либо подобного).

Проблема в том, что я обнаружил, что приложение использует IdT1 в TABLE2 для (правильного) хранения строки, на которую ссылаются, в TABLE1, , но также использует ноль (0) для особого случая.

Итак, у меня есть (в Таблице 2) что-то вроде этого:

IDt2 IdT1 OtherFields
1    1    x
2    1    x
3    5    x
4    0    x
5    3    x
6    0    x
…

Как вы можете видеть в строках 4 и 6, FK указывает на несуществующую строку в TABLE1. Программное обеспечение работает, потому что у него есть (много) мест, где оно «отслеживает» это с помощью оператора IF или подобного. Изменить это сейчас не очень хорошая идея (я бы не хотел касаться кода, который «работает, а я не писал» прямо сейчас), если только это не единственный способ.

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

Учитывая приведенный выше сценарий, могу ли я создать FK, который не проверяет ограничения «никогда»? Будет ли это «проблемой» (учитывая, что приложение работало более 5 лет с этой штукой Id = 0 в ФК)? У вас есть какие-нибудь предложения? Tks.

Answer 1

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

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

Answer 2

Если вы хотите создать FK и не хотите, чтобы он проверял existing данные, вы можете использовать WITH NOCHECK ... но, опять же, в этом случае вы просто уничтожаете всю цель FK. Также имейте в виду, что ограничения, определенные WITH NOCHECK, не учитываются оптимизатором запросов