Сообщений в теме: 40

[Visual1]

>Если я не прав, то укажите, плз, в чем?
Вот в этом:
>"Access поддерживает не все ключевые слова ANSI SQL,
> но каждая модификация Jet отвечает стандарту SQL-92."

Третий раз повторяю, теперь уже специально для вас. Это не мое мнение, а цитата, дословно приведенная мной из книги.

Кстати, если автор настолько проффесионал - почему же родную документацию не читает?-) Ссылку я приводил.

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

>MS SQL Server, который из всех существующих наиболее близок к стандарту ANSI SQL
Тоже перл Так что по рублику со всех, а то пивнушку закроют

Вы не согласны? У вас есть другое мнение? Тогда почему вы способны всего лишь на иронические слова и ухмылки? Более серьезных доказательств у вас нет?

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

[Gloomy]

По теме?

Мда как то мы в высокие материи ушли Ну да вот - исправляю положение:

Известно что SOUNDEX не работает с русским. Все плохо даже если затранслитить. А вот MetaPhone - можно запинаить. Вот за __5__ минут нашел. Как раз для Access:
http://kankowski.nar...metaphoneru.htm
И для Transact-SQL:
http://www.softmatics.ru/sql/14.htm

Так что вперед, программеры!

PS: А по рубчику все же ..... ухожу - ухожу ))

Сообщение отредактировал Gloomy: 30.09.2004, 09:58:41

[BIGGboss]

OFF. А может на основе игрища "Поля Чудес" статистику русских буковок для SOUNDEX сделаем?

[Shirson]

Статистику повторяемости? Её за 10 минут можно сделать и без ПЧ.

[Gloomy]

Ее и "делать" не надо - любой отечественный труд по криптографии почти обязательно имеет такую табличку, чтобы продемонстрировать что простые подстановки - suxx
Только SOUNDEX с русским все равно дружить не будет. По другому язык устроен. А потому и метода нужна другая

[Visual1]

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

[lPhreon]

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

[Shirson]

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

Второй пост в этой теме не читали?

[Visual1]

2 Shirson:

Второй пост в этой теме не читали?

Читал, конечно. Там предлагается использовать "вордовский спелчекер", но не говорится, что этот спелчекер - вообще-то не "вордовский", а общий компонент для всех продуктов MS Office. Не говорится также, что есть хотя бы одна СУБД (и если есть, то какая?), в которой можно этот спелчекер напрямую (минуя Word) использовать для контроля правописания в поле таблицы БД.

2 Iphreon:

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

1. Почему только "на этапе ввода"? А после ввода в любой момент разве нельзя запустить и проверить?
2. Словарный запас фамилий можно пополнять, благо есть возможность расширять основной словарь дополнительными пользовательскими словарями (файл custom.dic). А что, существуют какие-либо готовые решения для фамилий? Укажите, плз.

Сообщение отредактировал Visual1: 07.10.2004, 22:45:06

[Коляныч]

вообще тема разве про спеллчекер? Если я правильно понимаю, то нужно отлавливать именно фонетическую похожесть слов, которые могут и отсутствовать в словаре (Айжан ~ Айман ~ Арман).

И в смысле фонетической похожести транслитерация с последующим стандартным difference даёт вполне работоспособную версию


difference('Ayzhan','Ayman') = 3
difference('Ayman', 'Arman') = 3
difference('Ayzhan','Arman') = 2

даже такое прокатывает:
difference('Bulat', 'Polat') = 3

[Shirson]

Читал, конечно. Там предлагается  использовать "вордовский спелчекер", но не говорится, что этот спелчекер - вообще-то не "вордовский", а общий компонент для всех продуктов MS Office.

А это что-нибудь меняет?

Не говорится также, что есть хотя бы одна СУБД (и если есть, то какая?), в которой можно этот спелчекер напрямую (минуя Word) использовать для контроля правописания в поле таблицы БД.

Да, и не преведён полный код посика и проверок. И много еще чего "не".
Тут общие идеи высказываются, а не кокнретные реализации.
Я, в отношении к MSSQL, могу этот спелчекер использовать, и в хвост и в гриву. OLE никто не отменял. Но конкретики тут задано небыло. Ни по СУБД, ни по чему другому.
Опять же, имена собственные спелчекер сливает с завидной постоянностью.
Проверять заполенные поля потом, уже в базе, занятие тоже малоприятное. Учитывая, что это опять же, это имена собственные.
А заводить custom.dic и пополнять его фамилиями это сложная реализации простой вещи - завести в самой базе список фамилий и пополнять его.

[Visual1]

Читал, конечно. Там предлагается  использовать "вордовский спелчекер", но не говорится, что этот спелчекер - вообще-то не "вордовский", а общий компонент для всех продуктов MS Office.

А это что-нибудь меняет?

Конечно, меняет. Повторяю, можно обращаться к спелчекеру напрямую из БД, минуя Word. Предварительная работа по проверке вводимых слов в Word'е не требуется.

Да, и не преведён полный код посика и проверок. И много еще чего "не".

Именно потому я и добавил кое-что, полагая, что это не помешает. Или кому-то все же мешает?

Тут общие идеи высказываются, а не кокнретные реализации.

Кто это правило установил? Почему его надо выполнять? Если существует конкретный продукт, в котором эта проблема уже решена, тогда что, следует о нем помалкивать?

Я, в отношении к MSSQL, могу этот спелчекер использовать, и в хвост и в гриву. OLE никто не отменял. Но конкретики тут задано небыло. Ни по СУБД, ни по чему другому.

Ой ли? А в посте номер 1 говорится "к примеру, имеем поле в базе данных..."

Опять же, имена собственные спелчекер сливает с завидной постоянностью.
Проверять заполенные поля потом, уже в базе, занятие тоже малоприятное. Учитывая, что это опять же, это имена собственные.

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

А заводить custom.dic и пополнять его фамилиями это сложная реализации простой вещи - завести в самой базе список фамилий и пополнять его.

Это простая реализация одной и той же вещи. Разница всего лишь в том, что в случае файла custom.dic выполняется обращение не к локальной таблице БД, а к внешней БД, хранящейся во внешнем текстовом файле (custom.dic). Достоинством этого подхода является возможность проверок при работе во всех офисных программах, не только для контроля правильности записей БД, но и при подготовке текстовых документов Word и таблиц Excel, в которых могут встречаться аналогичные имена и фамилии.

[mparygin]

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

для искомой строки делал то ж самое

теперь остается найти несколько наиболее совпадающих (хоть каким способом - хоть наименьшими квадратами) хешев....

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

в итоге юзерь получал бы самое совпадающее затем с переставленными буквами
затем с пропущенными буквами затем с лишними буквами.

4экземпл

слово: МУХА - таблица А-1,М-1,Х-1,У-1.
слово: БЛЯХА - таблица А-1,Б-1,Л-1,Х-1,Я-1.

искомое слово: УХА - таблица А-1,Х-1,У-1.

сравниваем по наименьшей разнице

разница МУХА-УХА == 3 совпадает и 1 лишняя буква == +3 - 1 == 2 балла
разница БЛЯХА-УХА == 2 совпадает и 3 разных == +2 - 3 == -1 балл

получаем что слово муха более подходит


Метод можно сильно усложнить и учитывать что угодно - хоть фонемы.
из постановки задачи - на проверки ошибок ввода - по моему самое оно.

[Shirson]

Конечно, меняет. Повторяю, можно обращаться к спелчекеру напрямую из БД, минуя Word. Предварительная работа по проверке вводимых слов в Word'е не требуется.

И БД эта Access, а все остальные как?

Кто это правило установил? Почему его надо выполнять? Если существует конкретный продукт, в котором эта проблема уже решена, тогда что,  следует о нем помалкивать?

Это правило установил автор вопроса, не указав никакой конкретики. Может он на Жасмине работает, откуда мы знаем?

Ой ли? А в посте номер 1 говорится "к примеру, имеем поле в базе данных..."

И что? DTS отменили? External XP отменили? Триггеры отменили? Клиентскую часть отменили?

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

Вообще-то тут решение нужно, а не возможность Возможность проверки, которая не является решением - не является решением.

Это простая реализация одной и той же вещи. Разница всего лишь в том, что в случае файла custom.dic выполняется обращение не к локальной таблице БД, а к внешней БД, хранящейся во внешнем текстовом файле (custom.dic). Достоинством этого подхода является возможность проверок при работе во всех офисных программах, не только для контроля правильности записей БД, но и при подготовке текстовых документов Word и таблиц Excel, в которых могут встречаться аналогичные имена и фамилии.

И годится только для Access, которая не является единственной используемой. И автором в вопросе не было указано, на какой БД он это реализовывает.
А общее решение, для всех БД, это список заранее заданных значений. Без привязки к ворду, акцессу или офису вообще.

[Коляныч]

mparygin
другиим словами предлагаешь ввести понятие "расстояния" между словами, как элементами некого словесного множества.

тогда можно переформулировать задачу по другому (если всё-таки оказалось, что основная задача - не война с фонетикой, то тогда про soundex дружно забываем):

имеется два слова S1 и S2
вопрос: последовательность из скольки элементарных опреаций переводит слово 1 в слово 2?

элементарными операциями считаются:
1) пропуск одной буквы в любой позиции
2) вставка одной лишней буквы в любую позицию
3) перестановка местами двух рядом стоящих букв
4) изменение одной буквы на другую в некоторой позиции

при желании операциям можно назначить веса и искать последовательность переходов с минимальным весом. Полученный вес будет мерой "расстояния" между словами, чем он меньше, тем слова более похожи

[Visual1]

И БД эта Access, а все остальные как?

Напоминаю, вопрос автора был:

как найти слова как нормальные так и с ошибками?

На этот вопрос ответ мной был дан - использовать запросы SQL с оператором LIKE и символами подстановки. И на ваш вопрос "а все остальные как?" этот ответ также является правильным, если эти все остальные поддерживают язык запросов SQL (кто ж его не поддерживает? пусть даже с некоторыми отклонениями от стандарта). Ну, а если в качестве БД использовать Access, тогда будут еще кое-какие дополнительные преимущества, в виде уже имеющейся встроенной, достаточно удобной, предварительной проверки ошибок ввода по словарю, который к тому же используется всеми остальными программами семейства MS Office.

Это правило установил автор вопроса, не указав никакой конкретики. Может он на Жасмине работает, откуда мы знаем?

...Но и не запретив никакую конкретику в наших ответах. Между прочим, вполне конкретные вещи - MS SQL Server, Soundex и возможность проверки ввода спелчекером в Word - раньше всех были указаны вами. Тогда вы и есть первый нарушитель правила "никакой конкретики", если только оно вообще было установлено.

Вообще-то тут решение нужно, а не возможность  Возможность проверки, которая не является решением - не является решением.

И в самом деле, кто бы с этим утверждением спорил, только не я.

И годится только для Access, которая не является единственной используемой. И автором в вопросе не было указано, на какой БД он это реализовывает.
А общее решение, для всех БД, это список заранее заданных значений. Без привязки к ворду, акцессу или офису вообще.

"Общее решение, для всех БД, это список заранее заданных значений" ©Shirson - это ценное разъяснение, поэтому прошу при дальнейшем цитировании нигде его не выбрасывать. Вы легко получите это общее решение, этот список заранее заданных значений (в том числе и с ошибками типа "Свелтый Путь"). Для этого, как я уже ранее говорил (вынужден повторять), нужно применить в команде SELECT оператор LIKE со специальными знаками подстановки для неизвестной группы символов и/или символа. Без привязки к ворду, акцессу или офису вообще - как вам, собственно, и хотелось.

[mparygin]

2коляныч

именно это
заранее вычислив вес
процедура поиска превращается
в арифметику

[Tolich]

А вообще.. где ошибка то?
ТОО Светлый и ТОО Свелтый совершенно разные клиенты.. и может быть ТОО Свелтый даже более правильный..
Если пользователь правильно искал ( в твоем случае неправильно) и не нашел, значит нету такого.. Пусть ищет другим способом, если уверен что где-то есть.. правильно Светлый пишет или по РНН ищет(не факт что он тоже верно вколотит)
Вот если в базе ошибки - тут косяк пользователя.. система как ни крути врядли подскажет что фамилия правильно/неправильно написана.. такие подсказки раздражать только будут при вводе. Да просто по шее пользователю за некорректные данные, глядишь внимательнее станут!!!

Потом.. совет.. клиентов такого рода лучше называть СВЕТЛЫЙ ТОО, чеб индексы эффективно работали

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

Мне кажется написание таких алгоритмов дело неблагодарное.. об эту тему уж много копий побито...

2 mparygin.. Интересно попробовать на большой базе.. мне кажется все равно неэффективно будет.. наверняка левых выдавать будет, к делу не относящихся

[mparygin]

2 tolich

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

[yedyge]

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