| |
|
|
| | Имеется, к примеру, запрос на поиск дублирующих записей:
SELECT Tab1.Фамилия, Tab1.Имя, Tab1.Отчество, Tab1.ДатаРождения
FROM Tab1
GROUP BY Tab1.Фамилия, Tab1.Имя, Tab1.Отчество, Tab1. ДатаРождения
HAVING (((Count(Tab1.ID))>1));
Каким образом можно, к примеру, в [Фамилия] сделать допуск на отбор записей с расхождением в одну букву, к примеру – Ивонов и Иванов? | |
| |
| |
| |
 38 Кб. |
|
| | Умных мыслей не посетило, потому выкладываю те, которые "сами пришли". 
Сделал табличку t1, добавил мало-мало записей =>
Сделал табличку tblTemp, добавил в нее функцией "маски" для фамилий из таблички t1.
Запросом объединил таблички с условием, сгруппировал, посчитал (qdf1).
Что-то вроде желаемого получил.
Но, на хорошую скорость, при больших исходных данных, рассчитывать не приходится. | |
| |
| |
| |
|
|
| | Спасибо!
Но проблема в следующем: Взять сотню-две-три самых распространённых русских фамилий или имён или отчеств и описать в маски – то будет где-то, к примеру, под 30 тысяч записей в Ф или И или О. Это уже их писать не описать (если только не выбрать заранее правильные варианты и задать возможные изменения программным способом – автоматизировать изготовление масок). Сравнивать с 700 тысячами не трудно, можно и на ночь оставить. Но я живу не в России. Казахстан. Казахских разновидностей ФИО больше на порядок или два, описать их все будет ну очень трудно, а ошибки при наборе допускают в основном в них. Одна ошибка, к примеру, в имени ещё одна в номере документа и вот – новый человек, а на самом деле двойник-дублёр, и надо их отыскивать в конце рабочего дня. | |
| |
| |
| |
|
|
| | есть функции нечеткого сравнения строк (где-то на этом форуме я встречал)
только ошибки с такой формулой надо не в конце дня отлавливать а в момент ввода информации
т.е. ввели инфу в несколько полей - после объединить все поля в одну переменную и прошерстить базу на предмет совпадений (в данном случае примерных)
если найду пример то выложу | |
| |
| |
| |
|
|
| | В изначальном наборе данных для создания "масок" должны быть отобраны записи,
сгруппированные по Имени, Отчеству и ДнюРождения, имеющие количество Фамилия более 1.
Это значительно сузит поиск .
Кстати, условие с LIKE в запросе не нужно, и без него все считается. | |
| |
| |
|
|
| |
|
|
| | Час – я твой пример посмотрел первым делом, но что-то пока не сумел его приладить под свои нужды. | |
| |
| |
| |
|
|
| | Не проще ли по ходу ввода отфильтровывать уже тех, кто есть на данную фамилию, затем на имя и т.д. А уже из тех, кто появился отбирать. Хотя даже в этом случае от ошибок никто не застрахован. | |
| |
| |
| |
|
|
| | +1024!  | |
| |
| |
| |
23 Кб. |
|
| | вот => | |
| |
| |
| |
|
|
| | snipe – Спасибо!
Сейчас поупражняюсь в реальных условиях!
| |
| |
| |
| |
|
|
| | СилЫч! Я здесь, когда бывал в начале 2000-х, по-моему, ты здесь старожил (мне так помнится), был здесь Марат, который из Америки, рассылку на городском коте ещё он вёл. Случайно не знаешь, что с ним? Где он сейчас? | |
| |
| |
| |
|
|
| | 
да пребудет с нами Марат!
живёт в своём заокеанье :) детей растит, работает
у него всё ок
найти можно на форуме http://www.ourprivate.net/forum/
| |
| |
| |
| |
|
|
| | Очень много разновидностей ФИО и база большая, мне кажется что фильтровка по вводу тормознёт работу. Набор в день по 300 записей. | |
| |
| |
| |
|
|
| | 300 в день это круто. Но уже 2 года работает база по 15-20 записей в день. С этой справляется без замечаний. (пока) | |
| |
| |
| |
|
|
| | Эксперимент по внедрежу прошел не так как надо.
Большие задержки при больших количествах записей. Ну а самое главное – это человеческий фактор. Работа построена следующим образом: есть одна постоянная наборщица с опытом работы (старшая среди них) и есть привлекаемые эпизодически специалисты (зависит от объёма работы, в разное время года разный). Так вот – вот эти эпизодические впадают в такой ступор при принятии решения по поводу двойников, что никакой windows с её зависаниями и не снилось. Непосильная задача, оказывается, для неподготовленного человека определить, где же иногда правильное написание ФИО.
И теперь склоняюсь к решению, что в моём случаи правильней бы соединить Фамилию, Имя, Отчество, ДатуРождения в одно поле и искать совпадения с определённым допуском (одна или две буквы или одна цифра в дате рождения). Всё это делать в конце рабочего дня или там, в конце недели и отдавать на корректировку старшей наборщицы.
Может, кто-нибудь, посоветует что-нибудь по этому поводу? | |
| |
| |
| |
|
|
| | Может как вариант
сделать поле Boolean - типа проверено
мартышки, осьминоги и т.д. тупо забивают данные но это поле не трогают
а более опытный запросом выбирает введенные данные и проверяет на совпадения - далее заполняет это поле
Объединять инфу - тут все мое естество противится (чем дискретней - тем лучше) собрать инфу в одно поле легко, а вот разъединить - проблематично
Более того в том примере что я вам присылал в функцию передаётся именно объединенная переменная состоящая из Фамилии Имени Отчества ДатыРождения (одно словом в общем-то) | |
| |
| |
| |
|
|
| |
соединить Фамилию, Имя, Отчество, ДатуРождения в одно поле и искать совпадения с определённым допуском
|
это можно сделать в запросе а не в таблице [FirstName]&[MiddleName]&[LastName]
существует правило - информация верифицируется по месту ее появления. дополнительные проверки мероприятие затратное и не надежное.
меньше всего ошибок бывает (последовательно) в именах, отчетствах, фамилиях -, соответственно в такой последовательности и нужно верифицировать данные а не по полному стрингу ФИО | |
| |
| |
| |
|
|
| |
...(последовательно) в именах, отчеТствах, фамилиях ...
|
Последовательность неправильная... | |
| |
| |
| |
|
|
| | Может
юзеру показывать дополнительные данные (помимо Фамилии Имени Отчества и Даты рождения) на основании которых можно однозначно идентифицировать информацию
(например место рождения, место регистрации, место жительства, номер паспорта и т.д.) | |
| |
| |
| |
|
|
| | Данные поступают из разных источников. Содержат разный набор данных. Гарантировано только ФИО и ДатРож. Всё остальное по усмотрению подающих данные (вернее от их безалаберности в вопросе подготовки данных). Ответственность за правильность написания не несут (наказать законным способом за ахинею в данных пока ни кого не смог). Достаточно сделать одну ошибку в ФИО и номере документа как появляется другой человек. Всё дело в том, что это Казахстан, в котором, ну, наверное, на два порядка больше разновидностей ФИО чем в России (за исключением входящих в состав республик, АО или тому подобных нацформирований) это при том, что население в 10 раз меньше. Очень много людей, у которых в действительности при совпадении на 99% ФИОДатРож отличается только номер документа. Но безалаберные подающие данные организации умудряются до 20% поданных номеров документов искажать.
Вот и приходится только опираться на ФИОДатРож, с надеждой на то, что будет для опытного человека очевидной ошибкой. Проверять по ном доку или иным номерам приходится очень редко, редко дают обновлённые данные подобного рода для глобальной чистки. Приходится на интуицию полагаться.
Snipe – подскажи, пожалуйста, как можно (лучше или эффективней) твой пример использовать для запуска эпизодической проверки на двойников? Чойто я не совсем соображу.  | |
| |
| |
| |
|
|
| | вечером дома подумаю
работать осталось 40 минут а тут нагрузили как баржу утюгами | |
| |
| |
| |
|
|
| |
для запуска эпизодической проверки на двойников
|
мысля -
проверка на совпадающие это хорошо, но если
создать таблы ФИО_Эталон Имя_Эталон Отчетво_Эталон - куда вносим все поступающие правильные данные один раз и к ним привязываем все варианты найденных ошибок, как бы создаем базу ошибок - то со временем можно не сравнивать эталон и вводимый, а проверять на совпадение в базе ошибок - которая и даст нужный рэзультат. понятно что оно потребует времени. | |
| |
| |
| |
|
|
| | Проблема в том, что "правильным" считается не то, как оно по грамматике, а то, как оно в документе написано.
Уже народ поимел кучу проблем с той-же парой букв е-ё.
Причем служить в армии или сидеть в тюрьме "разрешается" с любой буквой,
а получить пенсию, например, с "не той" буквой - фиг вам. | |
| |
| |
| |
|
|
| | Семёны – Алёны и т.п. проблема большая, кто в документах идёт с «ё», а кто и с «е». Набирают с «е», после сверки с базой документов у кого «ё» меняю на «ё». Но у меня еще есть «к» и «к-с хвостиком», «н» и «н-с хвостиком» и др. Головоломка бывает конкретная. Имена могут быть написаны с любой из этих букв и быть правильными или быть с ошибками. | |
| |
| |
| |
78 Кб. |
|
| | Понимаю. Рекомендую из мизерного, но все же опыта. Для набирающих текст обезьян надо, что бы база сама ставила регистр, точки, пробелы, блокировала поля, если не заполнено предыдущее поле, а оно обязательно и т.д. Давала на просмотр инфу, которую будет добавлять в таблу и в таком духе. Но даже в этом случае будут ошибки.
Вот выдернул из действующей базы. (уже полгода работает без замечаний) Клиент должен вводиться только один раз, а там уже масса дат его посещений за жизнь. По мере ввода идет отсев. Если клиент уже был, второй раз ввести его будет невозможно. Убрать все лишнее (окно акса) из видимости (изобретение Лукаса), ограничить все права и т.д. | |
| |
| |
| |
|
|
| | ...(изобретение Лукаса)...
Изобретение не мое, а вот что "показал" его, уже жалею.
Нельзя скрывать окно Access-а, в сколь-нибудь ответственной поделке.
Только для баловства в личном пользовании!
Попробуй контекстным меню в форме перевести ее в режим конструктора. | |
| |
| |
| |
|
|
| | Если нужен конструктор - входим через шифт. Но из пользователей это мало кто знает. А так все пропадет и пустой экран будет. Так что это даже плюс, а не минус.
Ну и в крайнем случае для отключения этого режима заремить всего 2 строки на запуске формы. | |
| |
| |
| |
|
|
| |  
очипятка
иминах -> отчитствах -> хвамилийах
| |
| |
| |
| |
|
|
| | От теперь правильная. | |
| |
| |
| |
|
|
| | Промелькнула такая мысль
Если к Вам поступают данные из разных источников
то как получается что они не стандартизированы? (ответа на вопрос не требуется)
т.е. если организовать поступление данных по определенной форме и в электронном виде
то возможно внесение информации гораздо быстрее (и без привлечения сезонных работников)
возможно для этого придется написать маленькую базку и раздать ее поставщикам информации (бесплатно) в этой базке устроить кучу проверок при вводе инфы дабы избежать именно не правильного ввода инфы (ну там пробелы в начале и в конце слова, ввод правильных окончаний т.е. те которые пишутся через тире -оглы, - кызы, -оол - что бы пробелов не было (или наоборот было написано тире), написание имен собственных с большой буквы и т.д) кроме того установить кучу ограничений и условий на заполнение полей - а мысль простая - не хочешь делать сам, а надо - заставь других
более того - наказывать ни кого не придется - если не будут выполнены все условия то такая запись просто не сохранится и предоставлена не будет
останется только поиск дубликатов записей
по поводу ускорения проверки - мысль такая
есть таблица с данными и у каждой записи есть 2 поля (обзовем их поле1 и поле2) типа boolean для проверенной записи оба значения true для не проверенной - оба false
т.е. таблицу мысленно делим на три части (при помощи этих полей)
часть1 - состояние True True - запись проверена и она уникальна
часть2 - состояние True False - запись оператором не проверена, но проверена функцией и имеющиеся совпадения внесены во временную таблицу
часть3 - состояние False False - запись которую вносят пользователи
далее необходимо каждую запись из части2 сравнить с записями из части1
и каждую запись из части2 сравнить с записями из части2 и совпадения выгрузить во временную таблицу
теперь как я вижу реализацию - нужно очистить временную таблицу и сравнить все записи с false в поле2 с записями true в поле2 (поскольку записей много то такую проверку запускать на ночь) найденные совпадения выгрузить во временную таблицу и автоматом проставить true поле1(т.е. получится что непроверенная оператором запись но проверенная функцией будет иметь значение в полях True False - попадет в часть2)
Далее проверить записи в блоке True False (ведь за рабочий день могли тоже дубликатов набить) - данные внести во временную таблицу (т.е. каждую запись в блоке проверить на совпадение с записями в блоке свою запись в расчет не брать)
Теперь очередь оператора просмотреть записи false в поле2 и true в поле1(находящиеся в части2) и записи во временной таблице
если запись должна быть сохранена то в поле2 false меняем на true, а если дубликат то удаляем
если во время проверки будут внесены дополнительные записи то проверяющий юзер их не увидит т.к. оба поля False False (попадет в часть3)
в любом случае юзеру нужно показывать дополнительные сведения для принятия правильного решения (ну и что с того что Вы верифицируете данные только по ФИО и ДатеРождения - решение все равно принимать ему)
и еще - не рекомендую всю базу сразу проверять на совпадения - лучше кусочками (например добавить еще одно поле типа boolean и если True то с этими данными проводить проверку - со временем когда база вся будет проверена надобность в этом поле отпадет и его можно будет удалить) в противном случае возможен резкий скачек объема базы из-за временной таблицы | |
| |
| |
| |
|
|
| | Круто. Такой софт-ресурс для проверки только одних ФИО! Что говорить о других ошибках, при дальнейшем заполнении базы. Легче увольнять по статье за ввод 2-3 ошибок и лишать премии со штрафными санкциями. Автоматизировать процесс подачи заявления по собственному желанию после обнаружения 2 ошибок...
Ведь все опять сводится к оператору, (ОТК записей) которому принимать решение. Это один целый день косячит, а на следующий день целая армия проверяет его ошибки по результатам ночной деятельности программы. А те в свою очередь по-своему накосячат...
Предлагаю следующее. При обнаружении дубликата (Иванов-аглы и Иванов-углы) при идентификации, что это один и тот же (по дате рождения и по инициалам... отмечать обоих и объединять все данные под правильным именем, а неправильное уничтожать. Возможность этого действия свести к нажатию одной кнопки и выставлением пары галочек в любое время, когда будет обнаружение. Для этого применить поиск предложенный ранее снипом.
Бывало так и в моей базе, когда чел приходит второй раз, а его помнят, но найти не могут. Потом по результатам других записей находят и видят, что в фамилии накосячили. Переносят данные одной записи в другую и все. (полные данные каждой записи содержатся в 5 таблицах)(такое всего 3 раза было за полгода.) | |
| |
| |
| |
|
|
| | Дык, и увольняю … когда есть из кого выбирать, а так выращиваю «старших» (и то приходится менять, то в декрет уйдёт, то на нормальное место). Гос.орган, зарплата 150 баксов, ставка тех.работника, вот и приходится вести селекцию. С прогой для подающих данные пробовал лет так 5 назад, вообще амбец (от обвинений что у них перестал работать комп до того что прога специально вносит ошибки в их данные). Сейчас подающих можно наказать только за не подачу, а если подали то уже всё - они свой долг выполнили. Подают только на бумаге, они даже в excel умудряются так извратить данные, что на дешифровку уйдёт уйма времени (то пересортируют все столбцы по отдельности, то экзотический шрифт впендюрят).
Отлавливаю дублёров – то полное совпадение, то частичное (к примеру, Ф-И-ДатРож(полная или частичная)), то только номер документа иль другие номера (был запрет на ввод одинаковых (индексированное, совпадения не допускаются), но иногда оказывалось, что в базе был неправильный, пришлось отменить и править потом с помощью правильного сотрудника, то к примеру Имя-ДатРож(полная или частичная) и адрес (как показал опыт, самый эффективный способ, на удивление). По уникальности пройдусь – если 1 или 2 раза всего встретилась фамилия, имя или отчество, то уже повод для анализа. Есть подстановка при вводе (но это только частые русские или очень-очень частые казахские). Есть разные проверки типа – если фамилия на –ов то как правило и отчество должно быть на –вич и т.п.
Но, хотелось бы вылавливать за одно действие, а не разной кучей запросов, вот какие записи:
Просто, к примеру:
Ивановский Иван Иванович 01.01.1970
Ивановских Иван Иванович 01.01.1970
Ивановских Иван Иванович 01.10.1970 | |
| |
| |
| |
|
|
| | Не выловить. ХЗ может так и есть на самом деле. Решать не компу. Вероятность косяка 95% но 5% все же так. У нас был случай что одна и та же фамилия имя отчество появилось, только даты рождения разные. В замешательстве были все. Но оказалось, что разные товарищи и друг о друге ничего не знали. Разница в возрасте 5 лет была. Хорошо, что тот, которого вводили раньше не был. А если бы сказал, что бывал в нашей организации, попробуй того первого найди. ХЗ косяк или действительно так. Так что последние Ивановских - это почти наш случай. А с такой прогой как предлагается выше можно так накосячить, что базу придется обнулять. Выходы:
1 смириться.
2 каждому товарищу присваивать спец код (по счетчику) и что бы он этот код запомнил. (внести в паспорт особые отметки, дать карточку посещения...) Ну или записывать адрес, девичью фамилию матери, дату рождения любимой морской свинки посетителя и т.д. | |
| |
| |
| |
|
|
| | можно заключить договор со сторонней компанией на верификацию данных - такая услуга предлагается некоторыми.
поскольку у автора гос.компания - еще и бабла поотмывать пооткатывать можно
ЗЫ
а насчет отметок в паспорт - классная идея. раньше только украинские пограничники так развлекались | |
| |
| |
|
|
|
|
| |
|
|
| | Я гляжу тут дискуссия не умолкает..........
Уже Мюллировские методы в ход пошли...........
Кстати - его чевота не видна.........  | |
| |
| |
| |
|
|
| | Все мы под колпаком у Мюллера.  | |
| |
| |
