Sql Server 2008 - FullText округляет денежные значения? - PullRequest
Новая
       0

Sql Server 2008 - FullText округляет денежные значения?

2 голосов
/ 09 июля 2011

Предположим, у нас есть полнотекстовая индексированная таблица с этими записями: 

blabla bla bla 101010,65 blabla bla bla 
blabla bla bla 1012344,34 blabla bla bla

(десятичный разделитель по-португальски "," not "." Как по-английски)

Когда мы выполняем запрос вроде: 

where contains(field, "101011") or
where contains(field, "1012344")

Полнотекстовый движок возвращает эти записи, потому что мне кажется, что он округляет числа как: 

101010,65 becomes 101011
1012344,34 becomes 1012344

Есть ли способ избежать этого?

EDIT

Извините, я забыл сказать, что этот столбец является столбцом varchar max, а не столбцом валюты. Это происходит в этом поле, когда оно имеет значение с плавающей запятой, несмотря на то, что это столбец varchar

EDIT2

Это не единственные данные, которые у меня есть в моей колонке. Такие цифры часто встречаются в моих проиндексированных текстах. Это не связано. Как я уже сказал, это часть оригинального текста, и я ничего не сделал с оригинальным текстом. Я предполагаю, что это поведение средства разбиения по словам, но кто знает наверняка?

Ответы [ 2 ]

1 голос
/ 11 июля 2011

РЕДАКТИРОВАТЬ:

<Игнорировать> Причина такого поведения заключается в том, что средства разбиения по умолчанию для полнотекстового поиска SQL определяются английским языком (языковой стандарт 1033). В английском языке запятая является действительным средством разбиения по словам, тем самым разбивая ваш номер на два разных числа. Однако, если вы используете португальское средство разбиения по словам, FTS довольно умно сохраняет числа вместе. Попробуйте выполнить следующий запрос на SQL Server, чтобы увидеть, как механизм полнотекстового анализа по-разному анализирует один и тот же ввод в зависимости от указанной локали: 

--use locale English
select * from sys.dm_fts_parser('"12345,10"',1033,NULL,0)
--use locale Portuguese
select * from sys.dm_fts_parser('"12345,10"',2070,NULL,0)

UPDATE: Хорошо, мне удалось воспроизвести ваш сценарий, и да, это похоже на поведение по умолчанию с SQL Server FTS. Однако кажется, что он округляется только до ближайшей 1/10 числа (в вашем случае - до 10 сентаво), а НЕ до ближайшего целого числа.

Так, например; 12345,88 будет возвращено при поиске как 12345,88, так и 12345,9 , тогда как 56789,98 будет отображаться при поиске 56789,98 и 56790. Однако, такое число, как 45678 60 останется нетронутой без округления вверх или вниз, так что это не так плохо, как вы думаете.

Не уверен, что есть что-то, что вы можете сделать, чтобы изменить это поведение. Быстрый поиск в Google ничего не дал.

0 голосов
/ 09 июля 2011

Мое предложение было бы не использовать тип данных Money в первую очередь. Все, что вам нужно, - это небольшая простота форматирования (которую вы все равно должны делать на уровне представления), но это приводит к другим сложностям и негибкости. Я не уверен, что DECIMAL / NUMERIC решит эту конкретную проблему, так как я не полнотекстовый парень, но я стараюсь, когда могу, уводить людей от проблемных типов данных, таких как MONEY. Смотрите этот предыдущий вопрос для большого обсуждения по этому поводу. Следует ли вам выбирать типы данных MONEY или DECIMAL (x, y) в SQL Server?

...