|
|
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
Господа разработчики и АБД У меня к вам следующий вопрос возник. Наверное каждому из вас в той или иной степени приходится бороться с двойными записями в ваших БД (будь то БД по клиентам, посетителям больницы и т.п.), ведь человеческий фактор еще никто не отменял. Так вот и возник вопрос как бы написать такой запросище, чтобы это дело присекать. Хотелось бы услышать ваше мнение по этому вопросу. вот несколько соображений по этой теме. Двойники могут появляться 1 если какой нибудь ПЕТЯ начнет вводить клиента "Солнечный путь", а яжык переключит только после 2 буквы и тогда мы получим, что чистое сравнение на Name=Name пропустит, это хотя визуально их разве что БГ и отличит 2 тот же ПЕТЯ поставит лишний " " (пробел) или "."(точка) в фирме "ЗАО ХЕ регистр" Как кто решает такие проблемы извиняюсь если не сильно внятно объяснил, но надеюсь вы поняли в чем суть проблемы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 17:23:08 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
ИМХО, это надо лечить на клиенте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 17:25:46 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
ИМХО, это надо лечить на клиенте Это не на клиенте надо лечить, это тому Васе, который БД проектировал ручки поотрывать и выбросить нафиг. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 17:31:22 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
А что кроме имен у них нет других более нормальных аттрибутов,которые являлись бы уникальными(или набора аттрибутов),ведь "Солнечный путей" может быть сотня,но очень врядли что-бы у них был один р\с,или адресс,телефон или все вместе. Вот при добавке и проверяй все ето,у меня ето все зашито в ХП которая отвечает за insert. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 17:33:43 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
Как ? За спиной у каждого сотрудника, который может ввесли клиента стоять и долбить "А вы точно уверены что никто из 500 человек до вас не мог ввести этого клиента в БД под немного другим наименованием!!!" ??? нет тут на клиенте не побороть есть конечно несколько способ решения данной проблемы 1(и самый верный наверное) из них это растрел на месте того, кто нечаянно ввел клиента который уже был. Но мы ведь не месняки, правильно ;) хотя иногда руки к автомату тянутся. 2 метод это наверное всё таки поставить какие либо проверки в административных рассылках и капать этим товарищам переодически на лысину серной кислотой. Это наш метод ..., но как такую процу написать. несколько идей составление функции выдающей степень похожести одной строки на другую. так несколько правил которыми мы люди руководствуемся А (B & C) == A(B&C) == A (B&C) == и т.д. но это моё мнение (и я его конечно реализую) мне также интересно как другие смотрят на эту проблему ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 17:38:17 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
А что кроме имен у них нет других более нормальных аттрибутов,которые являлись бы уникальными(или набора аттрибутов),ведь "Солнечный путей" может быть сотня,но очень врядли что-бы у них был один р\с,или адресс,телефон или все вместе. Вот при добавке и проверяй все ето,у меня ето все зашито в ХП которая отвечает за insert. Мне бы может тоже хотелось это вшить в ХП но в этом то проблема и есть сначала вводят имя клиента, которое конечно же уникально, а уже потом указывают(возможно гораздо позднее) его р/с и прочие по настоящему уникальные атрибуты. Но первый человек ввел "солнечный путь" с первой английской буквы и поэтомы второй ПЕТЯ не задумываясь вводит и у нас совершенно благополучно существуют 2 клиента (2 баланса по ним). Т.е. вопрос не о том какие мы уродские разработчики, а о том как мы умеем решать поставленные проблемы. Проблема поставлена, как же вы её решаете ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 17:43:24 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
Тю блин ,а чем проблемма? Написать две ХП и прилепить на форму пару другую контролов + какой нибудь мсгбокс? И что месаж лень вывести "Вы уверенны в том что делаете". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 17:45:06 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
Почемучка, Вам Maxx уже объяснил суть Вашей проблемы. Ведь в жизни Вы как то отличаете соседа Петю и сослуживца Петю, у которых одинаковое имя но тем не менее это не один и тот же человек. И даже если они одинакового роста и по необъяснимой прихоти природы похожи друг на друга как близнецы их все равно можно отличить например по номеру паспорта. Дубли в таблицы могут быть только в двух случаях, точнее даже все равно в одном, в случае неправильного проектирования, когда нет возможности выделить РК. И даже если совершенно по независящим от Вас причинам у Вас нет полной информации о сущьности, все равно нужно предусмотреть какой то искусственный механизм для их различия. Ну например, каждому клиенту вручать идентификационную карточку, номер которой уникален и по которому можно будет различать записи о клиентах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 17:47:46 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
все таки конкретно это проблему я считаю нужно решать на клиенте.... реализаций может быть несколько... включая поиск вхождений похожих названий до добовления новой записи + диалог с пользователем... ЗЫ предусмотреть все глупые ошибки пользователя невозможно... но свести к минимуму / ;) муму / нужно стараться... потому и существует практика бэттатестирования.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 17:50:12 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
И всеже либо у Вас 2 Солнечных пути с одинаковыми атрибутами или один пустой(Одно название в мешанной кодировке),или извените - полное безобразие:))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 17:53:35 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
MiCe Я конечно же соглсен, что на клиенте это делать вещь замечательная. Либо в ХП занимающейся insert в БД клиентов. Так вот каким же собственно методом можно определить что любимому ПЕТЕ №2 нужно сообщить мол есть уже такая хрень, т.е. проца должна определить это и выдать что такой есть и юзай его. Не уж то у вас у всех БД с числовыми значениями и клиентов ваши работники различают по р/с и IdKlient :))) Какие проверки вы делаете перед тем как ввести новую запись. то Мaxx хуже у меня у обоих всё заполнено и по обоим куча документов выписано уже ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 18:00:49 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
Да ну фиг там(простите),при заполнении проверяеш в ХП все аттрибуты,если двойник сохраняеш в темповую таблу,возвращаеш клиенту данные с просьбой потвердить или чего еще сделать.....ждеш пока клиент думает,дождавшись ответа если да - инсертиш,если нет -делит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 18:07:18 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
у нас схожая ситуация... может поя вится сначала клиент, а уж потом дополнительная инфа .... а при создании нового клиента как я уже говорил поиск на вхождения таких же названий... предупреждения если слово смешанное(смесь кирилицы и латиницы)... обязательное выделение фрмы собственности в отделное поле... абревиатуру ( типа ТД, ПФГ, ...) расшифровывать и выносить так же в отдельное поле(таблицу)... оч много вариантов.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 18:07:50 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
а вот такой вопрос, как клиенту можно выписать счет, документы и т.п., если эти параметры еще не известны? вообще задача совершенно не тривиальная. я бы предложил как вариант на момент ввода некого уникального значения (например, ИНН, р/с, номер паспорта, что угодно)... вываливать пользователю список возможных конфликтов/совпадений. в этом случае можно заставить пользователя выбрать клиента из уже существующих или добавить нового... Если это уникальное значение не вводится, тогда забить на проверку вообще до тех пор, пока оно не будет введено. кроме того, как не крути, придется писать тулзы для объединения уже существующих под разными именами клиентов в одного... Например пЕтЮ_ и пЕТЮ в Петю. Ну и постоянно проверять БД, постепенно избавляюсь от глюков... старых и новых... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 18:13:50 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
согласен... тулз на объединение обязательно нужен... переодический скан(в конце дня,в конце недели...).. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 18:23:29 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
A voobsche-to u kazhdogo predpriyaiya est` registratzionniy nomer, a u kazhdogo cheloveka - nomer pasporta - dostatochno dlya unikal`nosti, po-moemu. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 18:47:16 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
не всегда есть возможность сразу узнать.... приходится исползовать некий докуммент до того как появятся детальная информация... просто таких нужно специально выделять.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 18:50:54 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
Это надо решать административными методами. Прежде чем завести клиента в БД надо получить от него исчерпывающую информацию. Кто он, что он и откуда. И самое главное определится с атрибутом который бы однозначно определял клиента. В случае фирмы это ИНН, в случае больницы - № паспорта или медицинского полиса. И проверку вешать на этот атрибут. Название фирмы, как бы точно ты его не ввел, может повторяться: какое-нибудь ООО "Надежда" из Москвы и ООО "Надежда" из Ставрополя вполне может быть. И Ивановых Иван Ивановичей тоже полно. И добавлять его в базу должен не первый попавшийся оператор, а специально выделенный человек. Если же на вводе сидят несколько человек, то в при добавлении надо автоматом записывать информацию кто ввел клиента и когда. В случае дублирования всегда найдется тот, кто это сделал. Я в одной фирме сделал подобную вещь, а директор издал приказ - в случае обнаружения дублей с виновника - 2% от зарплаты. Через неделю проблема была снята. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 19:07:32 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
угу.... ИМХО КЛИНТ ВСЕГДА ПРАВ..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 19:19:46 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
На мой взгляд, стопроцентного решения этой проблемы не существует, хотя все посланные ответы помогают решить ее частично. Даже лишение 50% зарплаты может не помочь в случае увольняющегося завтра оператора. Возможны ведь и другие ситуации. Например, какая-то фирма становится правопремницей другой. Пациент меняет фамилию, имя, отчество, пол, адрес, паспорт, а ИНН у него сроду не было, так как это противоречит его религиозным убеждениям. Ко всем данным решениям я бы посоветовал поставить на форме справочника ма-а-ленкую кнопочку - "Слияние". Если кто-то, неважно, сервер ли, по совпадающему ИНН, юзер ли, по знакомой морде посетителя, обнаружил двойников, то нажимается эта кнопочка, выбираются оба двойника и во всех таблицах ID "Второго" заменяется на ID "Первого". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2002, 21:06:36 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
Можно как угодно и сколь угодно помогать оператору не вводить инфу второй раз - вплоть до вывода списка похожих названий на основе аглоритма определения похожести звучания названий. И это есть правильно! Еще круче вариант (гы-гы-гы) - отличать их по ИНН, т.к. как я понимаю речь идет о юридических лицах. Вот и сделайте превое поле для ввода - ИНН. И все. Но вообще, если такая проблема уж существует и вдойников навводили - необходимо делать механизм слияния двойников для слияния из в ведомости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2002, 07:30:46 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
Да уж, проблемка животрепетная. И своего опыта: определите правила написания организации-например имеем два имени предприятия - краткое(для поиска, отображения) и полное (для отчетов, документов). Краткое пишется без кавычек и правовая форма в конце, например ООО "Ромашка" будет выглядеть как Ромашка ООО. Хорошо помогает избежать ввода двойников на первом этапе - "посмотри, нет ли уже такого в базе", особенно когда инфу заносит несколько операторов. Всегда отслеживайте и показывайте кто и когда завел запись, последним ее редактировал. Очень знаете дисциплинирует пользователя. К сожалению ИНН и номер паспорта (осообенно во времена смены таковых) не являются естественными ключами, да и информация на начальном уровне может быть неполная. К примеру для выписки счета достаточно наименование фирмы, а для счета фактуры данные уже нужны в большем объеме. Еще есть процедура проверки данных, запускается по желанию администратором или пользователем и возвращает сведения о подозрительных данных, неполных сведениях, каких-либо несоответствиях и т.д., вообщем чего бизнес-логика базы данных навеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2002, 08:44:51 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
to: Cat2 Зря Вы так ! на самом деле лишение 50% зарплаты помогает всегда ! Просто надо точно указать кого лишать ... но ето тоже не лучший выход ! Например можно подумать о следующем : Предположим, что речь идет о названии компании ... 1. Запретите вводить название в разных раскладках. 2. Ввод назввания производите в разных формах ввода, например ОАО вводить в водном поле а в другом "Солнечный ..." . 3. Запретите использовать заглавные и строчные буквы. Все ! Это решит проблему .... А как же с названиями, которые могут содержать и то и другое ... ? Да просто : Наделите одного человека правами создания таких названий и все ... Удачи ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2002, 09:18:49 |
|
||
|
убей двойника
|
|||
|---|---|---|---|
|
#18+
Polnostyu soglasen s AlexB. Nuzhno razrabotat` opredelonniy tehnologicheskiy protzess i utverdit` ego administrativno. Delal proekti v 3-h kontorah (po 200-300 rabotnikov kazhdaya) - vsyudu pomoglo reshit` bol`shinstvo problem. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2002, 09:36:44 |
|
||
|
|
start [/forum/topic.php?fid=46&msg=32040969&tid=1821209]: |
0ms |
get settings: |
6ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
43ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 202ms |
| total: | 311ms |
| 0 / 0 |
