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

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. Каков порядок трудоемкости разрешения коллизии (минуты.. часы.. дни..)