2013-08-23 2 views
0

Я пытаюсь написать простой запрос сравнения ключевых слов в mysql, но по какой-либо причине все числовое ключевое слово не будет соответствовать всем числовым терминам поиска.Строка и номер Mysql не равны/сопоставлены

У меня есть таблица продуктов, таблица ключевых слов и соединительный стол. Чтобы сделать вещи проще, я использую представление, которое выполняет соединение, предоставляя мне простой список строк ключевых слов для каждого идентификатора продукта. 1 продукт, в частности, имеет 4 ключевых слова: «John», «Deere», «8000», «Midroller», и они отображаются правильно в представлении и при соединении.

У меня возникли проблемы с тем, что (ключевое слово = "8000") никогда не относится к ключевому слову "8000".

Пример

SELECT a.id, kw.keyword AS keyword, (kw.keyword = 'John' OR 
    kw.keyword = 'Deere' OR 
    kw.keyword = "8000" OR 
    kw.keyword = 'Midroller') AS matched 
FROM `kc5n2_product` AS a 
INNER JOIN `product_keywords` AS kw ON a.id = kw.product 
WHERE a.id =119 

возвращает

 
id keyword matches 
119 8000  0 
119 John  1 
119 Deere  1 
119 Midroller 1 

Я имел взгляд на это: MySql: Compare 2 strings which are numbers? , но это не помогло.

Я также нашел это MySQL Query doesn't seem to be outputting expectations, но я пытаюсь сравнить их как строки, а не числа.

Даже пытаясь

SELECT a.id, kw.keyword AS keyword, (CAST(kw.keyword as Char(4)) = CAST("8000" as Char(4))) AS matched 

, чтобы попытаться заставить MySQL интерпретировать их как в виде строк не поможет.

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

kw.keyword LIKE "%8000%" 

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

Есть ли что-то очевидное, я делаю неправильно?

+0

Похоже, что в строке, содержащей '8000', могут быть ведущие/конечные пробелы – peterm

+0

Точно верно! Дополнительные пробелы не отображались в phpmyadmin, поэтому я даже не подумал проверить это. Это немного разочаровывает, что это было что-то такое основное. – DigitalArchitect

ответ

0

В подобных случаях это обычно означает, что ваше «неверное поведение» имеет в нем ведущие/конечные пробелы.

Вы можете найти всю эту «плохую» запись с запросом, как этот

SELECT * 
    FROM keywords 
WHERE CHAR_LENGTH(keyword) <> CHAR_LENGTH(TRIM(keyword)) 

Вот это SQLFiddle демо

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

UPDATE keywords 
    SET keyword = TRIM(keyword) 
WHERE CHAR_LENGTH(keyword) <> CHAR_LENGTH(TRIM(keyword)) 

SQLFiddle demo

0

Я не вижу ничего плохого в том, что вы опубликовали. Я устанавливаю тестовый пример:

CREATE TABLE product (id INT); 
CREATE TABLE product_keywords (product INT, keyword VARCHAR(32)); 

INSERT INTO product 
    VALUES (19),(20); 
INSERT INTO product_keywords 
    VALUES (19,'Foo'),(19,'John'),(19,'Deere'),(19,'8000'),(19,'Midroller'); 

SELECT a.id 
    , kw.keyword AS keyword 
    , (kw.keyword = 'John' OR 
     kw.keyword = 'Deere' OR 
     kw.keyword = "8000" OR 
     kw.keyword = 'Midroller' 
     ) AS matched 
    FROM `product` a 
    JOIN `product_keywords` kw 
    ON a.id = kw.product 
WHERE a.id = 19 

    id keyword matched 
------ --------- ------- 
    19 Foo    0 
    19 John    1 
    19 Deere   1 
    19 8000    1 
    19 Midroller  1 

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

Возможно, это проблема в вашем запросе на просмотр.

Что возвращает этот запрос?

SELECT kw.* FROM product_keywords kw WHERE kw.product = 119 ORDER BY kw.keyword ; 
+0

Он возвращает все четыре ключевых слова правильно. @peterm понял это, я немного раздражен, это было что-то очень простое. – DigitalArchitect

Смежные вопросы