Подскажите пожайлусата. можно ли организовать поиск в текстовом

← →
svt (2006-11-06 10:42) [0]

Подскажите пожайлусата. можно ли организовать поиск в текстовом поле без учета регистра. Если да то подскажите как.
Может существует специальная функция или что-то подобное. пока я не нашел. Заранее спасибо

← →
Stanislav © (2006-11-06 10:52) [1]

WHERE POLE like "%ghghg%", Только у тебя должна быть кодировка не учитывающая регистр, на сколько я знаю.

← →
Desdechado © (2006-11-06 10:59) [2]

WHERE Upper(fld) LIKE Upper( "%абВгд%" )
Но помни, индексы при этом использоватьсяне будут (если, конечно, они не построены по функции UPPER).

← →
svt (2006-11-06 11:09) [3]

весьма благодарен... но на сколько я понимаю это замедлид сам процесс поиска?

← →
Stanislav © (2006-11-06 11:25) [4]

svt (06.11.06 11:09) [3]
Ты попробуй у тебя like ищет записи без учета регистра, если нет, то придется использовать UPPER.

← →
svt (2006-11-06 11:38) [5]

> без учета регистра

пробовал... учитывает .... так что чере аппер будем реализовывать. сапсибо за совет. (и опять ... все гениальное - просто)

← →
sniknik © (2006-11-06 12:04) [6]

вообще серьёзные sql сервера такие как MSSQL поддерживают коллатионы (настройки и способы обработки для различный языков), то что учитывает/не учитывает регистр зависит от них, с каким COLLATE поле создано, если нужно чтобы не учитывало то лучше его пересоздать, если это редко (всегда учитываем, а в одно случае нет), то можно явно в запросе указать какой COLLATE использовать для этого конкретного случая.
это предпочтительнее чем Upper т.к. Upper это уже вычисление, индексы по вычисляемым не используются.
за подробностями в BOL.

← →
Sergey Masloff (2006-11-06 13:09) [7]

sniknik © (06.11.06 12:04) [6]
И что в MSSQL можно коллейтом задать зависимость от регистра в LIKE?
Мне казалось что как раз для LIKE поведение фиксировано стандартом SQL и от коллейтов зависеть не должно

← →
sniknik © (2006-11-06 14:08) [8]

и когда это мелкософт стандарты поддерживал? даже если это регламентировано (не уверен)
но неважно, можно (специально перепроверил на всякий случай - mssql2000).

← →
Anatoly Podgoretsky © (2006-11-06 14:25) [9]

> Sergey Masloff (06.11.2006 13:09:07) [7]
> Мне казалось что как раз для LIKE поведение фиксировано стандартом SQL и от коллейтов зависеть не должно

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

Тебя же не смучает StrFld=1 или DateFld="dd.mm.yyyy"?
А ведь это точно такое же преобразование.

← →
Bless © (2006-11-06 17:12) [10]

> sniknik © (06.11.06 12:04) [6]
> то можно явно в запросе указать какой COLLATE использовать
> для этого конкретного случая.

А можно ссылку в BOL, где описан такой синтаксис? Т.е. в примерах из той же BOL он попадается, но в описании синтаксиса WHERE я COLLATE-а что-то не нахожу. Это косяк BOL или я плохо/не там смотрю?

← →
sniknik © (2006-11-06 23:35) [11]

должен быть в описании поля (create/alter table) посмотри.

← →
Petr V. Abramov © (2006-11-07 00:06) [12]

а что бывают чудеса? и это преобразование быстрее upper и вдруг начнут индексы использоваться?

← →
sniknik © (2006-11-07 00:57) [13]

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

вообще нафиг, убеждать не буду, я сказал, ты услышал, дальше твое дело, хоть по-символьные преобразования к верхнему регистру делай.
но только в BOL-e конструкций подобных [2], не найдешь, единственное для чего upper там используется это для преобразований/изменений текста для вывода/перезаписи, но не в сравнениях, в сравнениях коллатионы... неспроста это, ой неспроста.

← →
Petr V. Abramov © (2006-11-07 01:04) [14]

> "индекс кейсе сенсетиве/и нет"
тогда да. дальше не читал :)
память vs процессор ТАКИМ образом решено, иногда полезно

← →
Anatoly Podgoretsky © (2006-11-07 09:29) [15]

> а что бывают чудеса? и это преобразование быстрее upper
> и вдруг начнут индексы использоваться?

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

← →
Anatoly Podgoretsky © (2006-11-07 09:32) [16]

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

Только не индекс, это шире.
Индексы будут использоваться, если они есть.
И там не только case sensitive, но и accent sensitive
Например найдет или сравнит слова Елка и Ёлка

← →
evvcom © (2006-11-07 10:35) [17]

> like "%ghghg%"

MS SQL 2000 будет здесь индексы использовать?

← →
Anatoly Podgoretsky © (2006-11-07 10:57) [18]

> evvcom (07.11.2006 10:35:17) [17]

Здесь не будет, а вопрос что про это?
Вопрос вообще не про индексы.
Зато найдет и ghghg, и GhgHg если будет установлен нужный коллайшен, не могу нормально это слово перевести на русский.

> MS SQL 2000 будет здесь индексы использовать?
сдесь нет. написал же, по возможности, а здесь разве есть возможность его использования?

> не могу нормально это слово перевести на русский.
легкая закуска. ;о))
по версии ABBYY Lingvo

но это последнее, первые идут
1) сравнение, сопоставление
2) сверка, проверка, сличение (текста, копий документов)
3) легкая закуска

> sniknik (07.11.2006 11:04:20) [20]

По версии ABBYY Lingvo, но в базах это имеет другой смысл, гораздо шире.

> sniknik © (06.11.06 23:35) [11]
>
> должен быть в описании поля (create/alter table) посмотри.
>

Ну про тот COLLATE, что в описании поля есть, я в курсе. Но ты ж написал " можно явно в запросе указать какой COLLATE использовать". Я почему-то подумал, что ты говоришь о SELECT. Проверил, не заругалось, да и в BOL нашел примеры такого синтаксиса (но не в описании синтаксиса SELECT).
SELECT (CASE WHEN id > 10 THEN GreekCol ELSE LatinCol END) COLLATE Latin1_General_CI_AS FROM TestTab

Уже не в первый раз попадается ссылка на синтаксис,
описание которого засунуто в такие дебри BOL, куда я лично могу попасть лишь случайно. И я все мучаюсь вопросом "откуда ж вы про него узнаете?" :) Неужели, прочитав BOL от корки до корки?

Хотя справедливости ради, применение COLLATE в SELECT-ах описан в разделе Collation Precedence, что не так уж трудно найти, хотя логичнее было б упомянуть его в описании синтаксиса SELECT.

> Я почему-то подумал, что ты говоришь о SELECT
я и говорил про SELECT, то что этого нет в его описании... ну не судьбы видимо.

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

> хотя логичнее было б упомянуть его в описании синтаксиса SELECT.
может быть, хотя наверное логичнее тогда в описании column_definition, отдельно от create/alter раз уж оно действует и в условиях, выборках, применимо везде где указывается/определяется поле.

> Bless (07.11.2006 12:35:22) [22]

> И я все мучаюсь вопросом "откуда ж вы про него узнаете?" :) Неужели, прочитав BOL от корки до корки?

Откуда, например из этого сообщения.
А ты что не читал весь BOL ты это напрасно

> Bless (07.11.2006 12:35:22) [22]

> Хотя справедливости ради, применение COLLATE в SELECT-ах описан в разделе Collation Precedence, что не так уж трудно найти, хотя логичнее было б упомянуть его в описании синтаксиса SELECT.

В SELECT можно много чего воткнуть, например хинты и их что тоже туда в описание? В описание достаточно воткнуть в See Also

> sniknik (07.11.2006 12:59:23) [23]

> хотя наверное логичнее тогда в описании column_definition, отдельно от create/alter раз уж оно действует и в условиях, выборках, применимо везде где указывается/определяется поле.

Да это относится к полю, а не к SELECT

Подскажите пожайлусата. можно ли организовать поиск в текстовом Найти похожие ветки