Matilda Cherstinужо и на форуме о проектировании БД вопрос поставлен, а идей - всё еще маловато будет...

а идей радикальных быть и не может - просто из анализа ситуации.

1. Если надо вводить всех (по первому контакту) - вводите всех. (никакой констрайнт на ИНН, совпадение, созвучие не спасет, как уже выяснилось).

2. Если при этом по возможности надо не вводить дубли - пишите не КОНСТРАЙНТ, а выдавайте информативное окно при вводе о существовании _Подобного_, где юзер мог бы уйти от ввода выбором аналога. Ответственность за выбор - на пользователе.

3. Процедуру (или запрос) выборки "подобного" сделайте отдельной. По мере уточнения алгоритмов (типов сходства) будете ее дописывать (перестановки слов, букв (та же транслитерация), и т.п.), не меняя всего остального.

4. И естественно нужна процедура ручного сведения дублей - та же подмена всех вторичных ключей. Хотя есть еще и метод не удалять "дубли" (и не замещать вторичные ключи) а хранить их как "представления" (поставив в них ссылки на "главное" или "корневое" представление) некой сущности. (тут важно организовать данные без кольцевых самоссылок. Например можно запретить узлам, на которые ссылаются представления, ссылаться на кого-либо (быть может кроме себя) - т.е. разрешить глубину ссылок не более 1. Как это сделать - вопрос к хранилищу данных. Если есть триггеры - то не триггерах, если нет - придется возложить контроль логической целостности на приложение.). И в _сводных_ отчетах по клиентам возвращать не "текущие представления клиентов" по записям, а всюду подставлять "корневые" представления. (запрос на замещение id при уровне ссылок не более 1 (т.е. 0|1) написать несложно на том же IIF(). Никакой рекурсии тут не будет). При этом вы получаете возможность оставлять в документах то представление (тот набор реквизитов клиента), который был при вводе документа, не перегружая базу необходимостью хранить в самих документах данные о клиенте в том виде, в каком они были на момент создания|редактирования документа, а создавая набор защищенных от редактирования (в случае ссылающихся на него существования документов) представлений одного и того же клиента.
Тут потребуется при "сведении" ранее независимых сущностей в одну определить, кто из них будет "корнем", а кто - представлением - т.е. кому переписать вторичный ключ (то ли Null, то ли себя самое - как вам удобнее) на значение этого корня. Никаких иных правок вторичных ключей (в других таблицах) при "сведении" таких сущностей в одну, но имеющую разные представления не потребуется.