Мы действуем так. В первую очередь ищем подходящих кандидатов по "id из внешней системы" (если есть), "тип-номер документа, удостоверяющего личность" (если есть), "ИНН" (если есть). Если не совпало, считаем запись новой. Если совпало, проверяем совпадение паспортных реквизитов, ИНН и даты рождения. Если все существующее совпало, полагаем что нашли героя. Если же "наполовину разошлись", например при том же паспорте другой ИНН, отбрасываем в ошибки на ручной разбор.

aagНесколько не понял - если совпал номер ДУЛ, снова проверяете совпадение уже полностью всех реквизитов паспорта?
Да. Чтобы исключить ошибочное отождествление из-за опечатки в номере.

aagИНН у физлиц, к сожалению не всегда возможно получить.
Паспорт, к сожалению, тоже. Я при изложении упростил алгоритм - чтобы подчеркнуть основу - а вообще у нас ситуация довольно интересная: нет ни одного обязательного идентифицирующего реквизита, нужен автоматический вердикт с практической гарантией недопущения ложного слияния, данные могут поступить из разных источников с интервалом в годы.

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

aagА если такие ФИО уже есть, а это однофамилец?
Полные тезки с одинаковой датой рождения приемлимо редки. Куда менее приятны дамы, меняющие фамилию и номер документа.

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

blindedЭто к сожалению невозможно. Представим себе ситуацию пришел Вася Пупкин, принес паспорт, вбиваю серию.номер, а под ней Жора Задов(ну кто-то ошибся ранее) что клиента гнать или Жору Задова искать?
Как Вы думаете, в том, что я написал, слово "сверить" присутствует просто так? Если под номером паспорта Васи вылезает Жора, это обнаружится (и так или иначе будет разрешено) при сверке оператором. Как именно производить сверку - отдельный вопрос, зависит от конкретной задачи; вопрос в том, что коллизия должна по возможности всплывать прямо у оператора - в тот момент, когда пришедший присутствует собственной персоной, документ можно посмотреть глазами и всю ситуацию - легко разрешить.

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

blindedНа самом деле проблема есть и будет и никаким образом ее строго решить нельзя.
(устало) На первой странице этого топика я излагал опыт решения куда менее приятной проблемы того же плана; не уверен, что Вы расскажете нечто новое для меня.

TаrantinoЭто из-за архитектуры системы т.е. есть точка продаж, она может быть очень далеко от москвы, в точке продаж "установлено" WEB-приложение, данные оттуда передаются в ЦО и проверятся по алгоритму который я описал, центральный сервер AS400, доступ к нему из точки продаж никто не предоставит в принципе.
Описанное Вами "web-приложение" не в воздухе же висит, на чем-то установлено? Кто мешает загнать на ту же машину необходимые паспортные данные и настроить периодическое пополнение базы из центра?

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

blindedа под ней Жора Задов(ну кто-то ошибся ранее) что клиента гнать или Жору Задова искать?
Фи. Даже забыл прореагировать - демагогия, прием называется "подмена бредом".

Нет, клиента гнать не надо, искать ли Жору - вопрос к постановщикам задачи. Что надо - заставить оператора тщательно сверить данные, дать зуб [зафиксированный в БД], что это данные именно Васи и пометить данные Жоры как неактуальные. В отличие от исходного алгоритма, который будет вынужден искать и Жору, и Васю, дабы выяснить, в ком из них сделана ошибка.

blindedТЕбе хорошо на эту тему рассуждать, когда у тебя база копеечная. А вот когда у тебя будет 40 млн вкладов в БД и 2-3млн операций в день, вот и посмотрим на хваленые алгоритмы слияния поиска и прочего.
Рассуждать - лучше, чем применять язык без участия мозгов.

blindedНа самом деле задачку решали как писал Tarantino,
Угу. Наиболее известный из всех аргументов - "мы делали так, поэтому над другим и думать не будем".

blindedПросто надо всегда быть готовым что база в этом плане будет всегда "грязной"
Надо, никто с этим не спорит. И если перестанешь соответствовать нику, сумеешь прочитать мои слова о том, что необходимость в очистке никуда не уйдет - но это не повод складывать в базу ту грязь, которую можно задержать на входе.

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

TаrantinoВсе зависит от задачи в нашем случае об этом не должен знать оператор и уж тем более клиент. Клиент должен думать что у него все хорошо и все идет по плану.
У клиента все хорошо, названный подход ему не мешает. "Не должен знать оператор".... странная постановка, но если так, то конечно, вариантов нет.

А что вы делаете, когда таки найдена подобная коллизия - "у кого-то из двоих неверные паспортные данные"? Или та проверка на фронте, которую Вы упоминали, состоит из онлайнового запроса в какую-нибудь паспортную службу [не знаю, существуют ли такие...]?

TаrantinoБаза из центра? ммм... я честно говоря плохо представляю какой должен быть комп у оператора а у них стоят ноуты.
При чем тут комп оператора? Вы сказали о веб-приложении, так? Значит, где-то стоит веб-сервер с этим веб-приложением, один или несколько. Этот сервер должен быть достаточно защищен (иначе любой желающий поработает на нем "вместо оператора") и скорее всего потянет паспортную базу без заметных усилий.

TаrantinoДа и с учетом того что сейчас таких точек продаж больше 1000...
И? Или Вы имеете в виду, что веб-сервер с приложением крутится на каждом ноуте?

TаrantinoДа и потом я сам не дам согласия на это не говоря уже о СЭБ, я думаю через неделю на митинском рынке будут продавать диска аля "клиенты банка ХХХ"
Согласен, безопасность здесь - основное, что может помешать. Но как я сказал выше, веб-сервер в любом случае должен быть неплохо защищен. Впрочем, это тот вопрос, который иначе чем на месте не решишь.

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

aagВ реальном мире решения о такой репликации принимает не Tаrantino и, скорее всего, даже не его начальник.
И? С моей точки зрения, если человек выдвинул какую-то позицию и не отмежевался от нее явно, предполагается, что он с ней согласен и готов объяснить-обосновать-защищать.

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

aagКак правило, у оператора недостаточно полномочий чтобы "помечать данные Жоры как неактуальные". Это не его сфера ответственности - он только докладывает по команде.
Согласитесь, конкретные детали здесь малопринципиальны с точки зрения обсуждаемого процесса. Главное - чтобы оператор "дал зуб" относительно того документа, который держит в руках, а как называть и расценивать эту пометку - "данные неактуальны", "доклад по команде с просьбой разобраться" итп - на принципиальную схему не влияет.

Tаrantinoкредит в магазине брали когда нибудь?
Я так похож на идиота?

Tаrantinoагент на точке просто вбивает анкеты и отправляет в бэкофис, после чего ему приходит либо положительное либо отрицательное решение, об этом он и должен сообщить клиенту, больше ему ничего знать не надо, особенно если отрицательное решение...
Cо скорингом таких анкет малость повозился. И какое отношение это имеет к ситуации "оператор ошибся при вводе данных"? Впрочем, дело ваше, конечно.

Tаrantino softwarerА что вы делаете, когда таки найдена подобная коллизия - "у кого-то из двоих неверные паспортные данные"?
все зависит от бизнес-процессов и они могут и что самое главное меняются
Хм.... как бы сформулировать вопрос, чтобы не натыкаться на ваши ограничения.... наверное так:

1. Как Вы оцениваете вероятность того, что после обработки такой ситуации в БД будут лежать правильные данные обоих указанных людей?

2. Каков порядок трудоемкости разрешения коллизии (минуты.. часы.. дни..)

blindedА в сберкассу ходили.
Задумавшись.... лет десять назад был пару раз :)

blindedТут хоть анкеты есть, а когда вклад принимают - просто от руки в рыбу договора вписывают.
От руки, конечно, еще хуже. За исключением бытующего кое-где идиотизма "вписать от руки, после чего оператор садится перебивать написанное в компьютер" :)

blindedДа и цель немножко другая - если деньги дают надо брать.
Другая по сравнению с чем? Такое впечатление, что Вы приписали мне какую-то цель, которой я не называл.

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

blindedНу один то точно будет неправильный
И это радует?

blindedВ случае кредита - могут деньги не дать.
Угу. Причем - по одной из двух причин:

1. Ошибка текущего оператора
2. Старая ошибка другого оператора

Имхо то и другое - потери, от которых стоило бы избавляться.

blindedВ случае депозита, решать будут потом, возможно не ешат никогда, вот клиент не приходит повторно и все.
Итого, имеем ситуацию "ничего хорошего: мусор в базе и необоснованные отказы в обслуживании". Не думаю, что это можно записать в плюс подходу.

Tаrantinoа причем тут скоринг?
Была у моего начальства идея такой услуги - именно для мгновенного ответа "да-нет" для потребкредитования. Спроса не нашла, что, впрочем, можно было предугадать.

Tаrantinoвероятность ошибки оператора на точке мала из-за двойного/тройного ввода
Хм. Это в веб-приложении то? А про существование Ctrl-C ваши операторы не знают? Я так подозреваю, что оператор у вас на точке один, и то, что вы попросите его трижды ввести некоторые данные, его мягко говоря, не свяжет.

Tаrantinoесли он не был идентифицирован то при попытке завести нового клиента в базе, будет отлуп т.к. клиент с таким паспорт уже есть, дальше по ситуации
Хм. То есть, если я правильно понимаю:

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

2. "По ситуации" - оно не очень информативно.. :)

Tаrantinoкредитование без скоринга? интересно... но в любом случае не понимаю причем тут паспортные данные
Шли в одной анкете и частично использовались при скоринге. Пол, возраст, место рождения - вполне себе показатели.

Tаrantinoконечно подозревают, но это легко отключается.
Хм. Не испытываю такой уверенности, но поверю на слово.

Tаrantinoего не спрашивают нравится ему это или нет, он пришел на работу и обязан работать в соотствии с регламентами и должностными инструкциями
Хм. Абсолютно уверен, что в регламентах и инструкциях есть пункт "не делать ошибок" - но это не значит, что операторы его выполняют :)

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

Tаrantinoсобственно если ему не отказали на идентификации и скоринге то проблем нет, он спокойно едет домой с новым чайником.
Не понял. Допустим, от оператора пришла запись "Вася Пупкин, паспорт 1111 111111" при наличии в БД записи "Абдурахман Хаттабов, паспорт 1111 111111". В смене имени Вася не признается. Он уйдет домой с чайником? Попадет ли его запись в БД?

Tаrantinoно такие ситуации крайне редки
Согласен. Большая часть коллизий приходится на расхождения написания того же человека, с чем, как я понимаю, вы справляетесь достаточно быстро.