Lotsia PLM: Форум по семейству систем PLM/PDM/TDM/ERP/Workflow

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

а можно ли как-то сделать предварительный поиск существующих? только непонятно как....
т.е. чел вводит "Мосводоканал" а в базе есть "Московский водоканал..." или наоборот - и создается двойник т.к. названия разные - а контора одна и та-же

как в этом случае произвести не четкий поиск существующего объекта автоматически?

может введенную строку разбивать допустим на 4 куска (как то обходя пробелы) и делать 4 запроса по LIKE???

или наверняка есть готовые алгоритмы на этот случай? - посоветуйте что нибудь

есть на Delphi http://www.delphikingdom.com/asp/viewit ... logid=1147
но встает вопрос как из действия запустить *.exe нет вопрос в том как из *.exe вернуть в действие список похожих объектов с их id??

Идея реализации с другой стороны... "административно - программная", есть такое понятие сокращенное наименование, т.е. чисто название без указания формы собственности или с ее указанием, так вот коротко я думаю поймешь...
Доводим до сведения всех как формируется сокращенное наименование... Далее создаем такой атрибут и все по нему и проверку делаем, таким образом получаем, пример:
полное наименование: ОАО "Московский водоканал"
сокращенное наименование Мосводоконал ОАО
вот и все решение

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

поэтому нужна только максимально быстрая автоматизированная фоновая процедура, поскольку у нас уже сейчас в таблице описаний клиентов более 25000 наименований

Ну тогда может через подстановку... т.е. на начинают вводить буквы а там вываливается список удовлетворяющий условию... если не найден... то создать новый... либо реально ввести некий добровольно-принудительный регламент ввода наименования организации...

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

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

Если сначала было введено полное наименование, а потом вводится сокращенное, можно предположить, что соответствие возникнет в том случае, если полное наименование содержит все без исключения символы сокращенного в том же порядке

'Московский водоканал' like '%М%о%с%в%о%д%о%к%а%н%а%л%'

А ведь классное решение...

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

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

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

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

Если всегда вводится полное наименование то можно воспользоваться SQL функцией Similar, которая оценивает процентное подобие строк (правда в документации Sybase SQL Anywhere указано что это Vendor extension, соответсвенно есть ли такой функционал на Oracle и MS SQL Server сказать не могу).

а это уже ближе к телу правда пока не совсем уловил смысл списка похожих - ведь если юзер вставит сокращенное (две буквы например) название то в этот список похожих залетит 1000 значений и никакого строкового атрибута не хватит их хранить или нет?

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

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

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

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

А можно попытаться усложнить задачу пользователю: в форме ввода делать поле с заказчиком только для выбора из имеющихся значений, т.е. из справочника. А свободный ввод разрешить только где-нибудь на последнем шаге. И то его пропускать, если заказчик уже выбран. Тогда пользователь получит некий бонус в виде укороченного действия, если выбрал заказчика из справочника или будет наказан лишним шагом, если этого не сделает. То есть ввести нового заказчика ему все равно придется, но кнопок понажимать придется больше.

А можно ежемесячно делать отчет, в котором будет сказано, что Ираида Петровна насоздавала пять (!) МВК и вот ей за это 5 пистонов