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

Кот МатроскинЭто зависит от области применения. Иногда хуже "не завести", иногда - "завести фигню".
Нет, от области применения это не зависит. Может зависеть от [плохого] дизайна БД, когда "завести фигню, смешав её с не фигнёй" становится ещё хуже, чем "не завести".

maytonБыл такой чел. Альфонс Бертильон. Давайте отдадим и ему должное.
Да, один из первых в мире специалистов по очистке данных :) Но сегодня его упоминание укладывается в уже обсуждённую дактилоскопию.

Кот МатроскинПри чем тут дизайн БД? вот пришел человек сделать у Вас некую транзакцию.
Это бессмысленная постановка вопроса. Человек не может "пришёл сделать транзакцию", он и слов-то таких не знает. На самом деле есть несколько фактов:

- человек предъявил такой-то документ
- человек внёс столько-то денег
- человек распорядился сделать с ними то-то
- итд.

Это всё - достоверная информация, которая может и должна быть зафиксирована и по результатам которой должны быть предприняты какие-то бизнес-действия. А если бизнес-действие - это "охранник ударил сзади по голове и оттащил в ОВД за фальшивый паспорт" - то тем более факты должны быть зафиксированы.

Кот МатроскинВам надо выдать ему подтверждение, что он-таки транзакцию совершил. Вы ее в какой момент будете выдавать? До "верификации"(tm)? - значит верификация бесполезна, обверифицируйтесь потом, но за транзакцию придется отвечать.
Глупость. Вот то самое БКИ, присылает мне банк "гражданка Петрова, паспорт 12345, принесла платёж по кредиту десять тысяч золотых рупий". А у меня паспорт 12345 записан на гражданку Сидорову. И по-Вашему, я должен зарубить нафиг транзакцию и велеть банку сказать "Нет, гражданка Петрова, не возьмём мы ваших странных денег, пока Вы не отыщете Сидорову и не решите, у кого из вас правильный паспорт".

Кот Матроскин"Жизнь сложнее схем" (с),
Верно. И именно поэтому любая "верификация, блокирующая вход" блокирует жизнь, как только та по каким-то причинам не впишется в схему. Хотя бы классический пример с дублирующимися ИНН: вот внёс один идиот unique key у себя в базе, а в результате какая-нибудь гражданка Сидорова не сможет оплатить штраф в ГАИ. Будет тыкать бумажкой в лицо: вот, смотрите, печать налоговой, они выдали мне такой ИНН, а сотрудники ей - гражданочка, ну не принимает программа ваш ИНН, ничего сделать не можем, это ваши проблемы.

Кот Матроскин По-моему, Вы должны вопрос "зарубать или нет" - согласовать с кучей заинтересованных лиц, ... Это вопрос не дизайна БД.
Неверно. Это два разных вопроса. Есть вопрос бизнес-логики: какое решение должна принять система в таких-то условиях. Я его ни с кем не должен согласовывать, его должны просто решить "заинтересованные лица", а я - в идеале - просто реализовать. В жизни, к сожалению, мне приходится таки выступить медиатором между этими заинтересованными лицами, дабы они не решили полной чуши. А есть вопрос технической архитектуры, в том числе транзакции, и здесь дело системы - зафиксировать факты и принятое решение.

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

Кот МатроскинЭээ, Вы поняли в моем сообщении слово "транзакция" как "транзакция БД"?
Нет, конечно, я имел в виду транзакцию как [некую] операцию в рельаном мире
Тогда напомню, с чего всё начиналось: 17023895