COMMUTATEUR avec COMME à l'intérieur de requête MySQL
J'ai cette table Tags
CREATE TABLE IF NOT EXISTS `Tags` (
`id_tag` int(10) unsigned NOT NULL auto_increment,
`tag` varchar(255) default NULL,
PRIMARY KEY (`id_tag`),
UNIQUE KEY `tag` (`tag`),
KEY `id_tag` (`id_tag`),
KEY `tag_2` (`tag`),
KEY `tag_3` (`tag`),
KEY `tag_4` (`tag`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=2937 ;
INSERT INTO `Tags` (`id_tag`, `tag`) VALUES
(1816, '(class'),
(2642, 'class\r\n\r\nâ?¬35'),
(1906, 'class\r\nif'),
(1398, 'class'),
(2436, 'class)'),
(1973, 'class:\n1.'),
(2791, 'classes'),
(1325, 'New'),
(2185, 'pack'),
(1905, 'packed'),
(1389, 'WebClass');
Je veux extraire tous les enregistrements où la balise correspond aux mots-clés class
ou pack
ou new
, avec un autre champ qui indique lequel des 3 mots-clés effectivement mis en correspondance avec le champ du tag.
La requête suivante ne donne pas de résultats corrects
Requête 1
select id_tag,
case tag
when tag LIKE "%class%" then "class"
when tag LIKE "%new%" then "new"
when tag LIKE "%pack%" then "pack"
end as matching_tag
from Tags
where tag LIKE "%class%" OR tag LIKE "%new%" OR tag LIKE "%pack%"
- Je utiliser les aimez à l'intérieur du boîtier. Sinon, correspondance complète des œuvres. La requête suivante fonctionne:-
Requête 2
select id_tag,
case tag
when "class" then "class"
when "new" then "new"
when "pack" then "pack"
end as matching_tag
from Tags
where tag = "class" OR tag = "new" OR tag = "pack"
Quel est le problème avec la requête 1. S'il vous plaît aider.
- +1 pour le ddl et les données de l'échantillon
- Quel est le problème ici? Requête 1 donne 11 résultats et il y a 11 entrées, qui est ce qui serait attendu. La clause where dans la requête 2 est différent et change le jeu de résultats.
- btw, vous pouvez utiliser
WHERE tag IN ("class", "new", "pack")
- Le problème est avec le matching_id colonne. Si vous exécutez la requête 1, vous verrez que contre
id_tag
= 1398, par exemple, matching_tag vientnew
, alors qu'il contient en faitclass
. De même, les différentes valeurs sont à venir pour tous les enregistrements, le nombre de résultats est toutefois correct - merci je vais l'utiliser.
- Désolé, comme les 2 requêtes ont donné la taille différente des jeux de résultats, je n'ai pas repéré le mal suite
- Cez - j'ai élargi explication sur ce qui se passe vraiment avec le cas... (explique pourquoi, pour id_tag = 1398 le cas des retours de "nouveaux" lorsqu'il contient de "classe").
Vous devez vous connecter pour publier un commentaire.
Mysql prend en charge deux types de cas, celle que vous utilisez dans la requête 2 est moins souple, mais ne supporte que l'égalité sur une seule variable. L'autre version indique l'absence de variable après l'affaire et puis les conditions ne doivent pas être seulement l'égalité:
Voir la documentation pour plus de détails
EDIT:
Voici un peu plus d'explication sur les raisons de votre requête #1 retourné ce qu'il a renvoyé:
s'attend à obtenir une valeur littérale pour la comparaison entre
when ... then
Dans le cas ci-dessus, les expressions
tag LIKE "%class%"
,tag LIKE "%new%"
ettag LIKE "%pack%"
sont toutes évaluées en avant le cas de la comparaison.Cependant (!), ce qui se passe, c'est qu'ils deviennent soit 0 ou 1, et lorsque comparée à la valeur de la balise c'est la première valeur de 0 qui correspond à tout caractère (char seront projetés à 0) - ceci est cohérent avec les résultats de votre première requête.
Voici une requête qui affiche les valeurs logiques pour les expressions:
C'est pourquoi vous obtenez des résultats inattendus; le silence de FONTE est un piège standard ici.
Veux juste rappeler, à propos de clause else: