Есть некий бизнес у которого есть клиенты, много клиентов.

И вот архитектор создает логичную структуру базы данных:
- Клиенты;
- Заявки, которые ссылаются на клиента.

В таблице клиентов все "чинно-благородно". ФИО, дата рождения, паспорт, контакты.

Всё хорошо, но в какой-то момент решили интегрироваться со внешней системой, а потом еще с одной и так далее.
И эти внешние системы присылают не всегда качественные данные. То паспорт может быть забит 111111, то телефон один на всех клиентов. Однозначно найти клиента в базе автоматически нельзя. Поэтому приходится создавать новых и новых клиентов.
Когда клиент приходит, его профайл, конечно корректируют, но и тут могут ошибиться.

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

Вопрос, как быть? Какие в этом направлении лучшие практики?

А вы автоматом себе в базу заливаете? А зачем?

Еще вопрос про архитектора... это вы штоле? или почему не он этим занимаетеся?

Для отсева некоторой части повторов можно проверять какие-то данные о клиенте, которые обычно обязательные, и имеют внутреннюю проверку валидности, ИНН - его сложно ввести криво при наличии проверки. СНИЛС, если физ лицо, тоже с проверкой. Вот паспорт не додумались так сделать, слова по этому поводу произносить не буду, но в 21 веке же, блин, вводили новый паспорт.

Во-первых, ясно дать понять, что архитектор существует для бизнеса, а не бизнес для архитектора. (А то почитал тут статейку на хабре, где чувак гордился, как он у "тупых менеджеров" выбивает себе и друзьям з/п, причем упорно апеллируя к тому, что менеджеры - тупые; смешно, короче.)

Что касается описанной ситуации (именно в той последовательности, как описано), то с учетом

> Когда клиент приходит, его профайл, конечно корректируют,

лично я бы предложил создать фоновую процедуру, которая бы раз в сутки, например ночами, бегала по базе и по каким-либо критериям сопоставляла клиентов, выявляя дубликаты. А далее условной девочке вменить в обязанность просматривать найденные возможные дубликаты и в случае, если девочка согласна с тем, что это дубликаты - то все сущности подвязывать к одной из записей (возможно, указанной как "главной" девочкой), а дубликаты удалять. (В интерфейсе непременно учесть, что могут быть тройственные совпадения и более.)
Алгоритм поиска дубликатов постепенно улучшать (на примерах из практики) как в сторону уменьшения ложных срабатываний, так и в сторону более хитрых способов выявления дубликатов.
Каким-то образом позволить девочке отмечать  "это не дубликаты, блин!!", дабы она каждый день не просматривала одни и те же ошибочно найденные пары.

Это не значит, что база в какой-то момент станет кристально чистой, нет, это просто обычная рутина должна быть в компании дабы поддерживать бизнес-процессы в приемлемом качестве.

> но и тут могут ошибиться.

Вот это не понял, признаться.
Если ошиблись - ну счастья-то не будет. хоть на этапе первичного заведения данных, хоть на этапе их корректировки. Не понятно что тут вообще возможно сделать.
Ну разве что приделать распознавание паспорта, где-то такие видел/читал, дабы уменьшить кол-во ошибок при первичном вводе данных.

ночные субботники. явка всех роботов предприятия строго обязательна.
все готовят данные для дневного принятия решения людьми.
https://dadata.ru/api/

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


А уникальный идентификатор клиента архитектор не придумал.
А проверять записи при интеграции сторонних баз программист не догадался.
А бить по рукам пользователей, которые забивают паспорт 111111 начальнику лень.


> Какие в этом направлении лучшие практики?


Все сжечь и переделать.

Мое имхо:
1. Наведение порядка в данном случае - ручной труд.
2. Дать возможность оператору, наводящему порядок, хорошие инструменты:
  а. Поиск возможных кандидатов на объединение.
  б. Удобным механизм слияния.

> manaka ©   (15.12.18 19:44) [6]
> А бить по рукам пользователей, которые забивают паспорт
> 111111 начальнику лень.

Сказано же: сторонний сервис. Кому по рукам бить?

> manaka ©   (15.12.18 19:44) [6]
> Все сжечь и переделать.

Молодой ты еще, горячий. Всё бы "переделать" всех кругом.

Добавлю. Вообще, такие вещи решаются имхо в директивном порядке:
а. Выбирается сотрудник, ответственный за порядок.
б. Ему вменяется в обязанность наведение порядка.
в. Ему даются средства наведения порядка.
г. Придумывается критерий успешности его работы.

Человека еще рано списывать в утиль. Как-то так.

> Какие в этом направлении лучшие практики?

Вот, книжку рекомендуют: https://www.ozon.ru/context/detail/id/19613873/

>manaka ©   (15.12.18 19:44) [6]

>А уникальный идентификатор клиента архитектор не придумал.
допустим, придумал
и архитектор сторонней системы придумал
и эти два идентификатора даже совпадут
с вероятностью, стремящейся к нулю

>А проверять записи при интеграции сторонних баз программист не догадался.
в исходной системе: 50 01 111111 Иванов Иван Иванович
в сторонней: 50 01 111111 Петров Пётр Петрович
в какой из систем ошибка?
проверяйте, нам не жалко

>А бить по рукам пользователей, которые забивают паспорт 111111 начальнику лень.
1. системы сторонние;
2. от ошибок ввода никто не застрахован.

>Все сжечь и переделать.
такие переделкины с гордо поднятой головой идут на рынок труда, подгоняемые ветром
из головы

> niteshade ©   (19.12.18 11:56) [11]
> такие переделкины с гордо поднятой головой идут на рынок
> труда, подгоняемые ветром
> из головы

Они вполне успешны
Так что не стоит завидовать )

>KSergey ©   (19.12.18 19:47) [12]
>Они вполне успешны
>Так что не стоит завидовать )
мнение не изменю
завидовать не перестану)

чем же дело кончилось ...

Пока идея такая.
Будут профайлы проверенные и непроверенные.

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

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

Для того, чтобы администратор мог выбрать правильное действие, ему в интерфейсе будет показан список всех проверенных профайлов, которые так или иначе по разным наборам признаков совпадают в исходным непроверенным.

уболтали архитектора? ))

Его просто убрали.