Bonjour à tous,

J'ai créé une requête qui ne fonctionne ni avec PHP PDO ni sur phpMyAdmin. Dans la clause WHERE f.id_subscrib=3 AND f.id=10, le deuxième terme n'est pas pris en compte. Pourquoi?

Note: Les valeurs sont des exemples.

Requête qui ne fonctionne pas:

			SELECT c.id
			FROM dat_customs c
				INNER JOIN lst_filters f
					ON c.id_subscrib=f.id_subscrib
			WHERE f.id_subscrib=3 AND f.id=10
			ORDER BY c.company

Pour une meilleure compréhension, la requête ci-dessus donne le même résultat que celle-ci:

SELECT c.id
FROM dat_customs c
WHERE c.id_subscrib=3
ORDER BY c.company

Définition de la table dat_customs:

CREATE TABLE IF NOT EXISTS `dat_customs` (
  `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `id_subscrib` int(10) UNSIGNED NOT NULL,
  `company` varchar(60) NOT NULL DEFAULT 'client=`id`',
  `fullname` varchar(100) DEFAULT NULL,
  `address1` varchar(60) NOT NULL,
  `address2` varchar(60) DEFAULT NULL,
  `country` char(2) NOT NULL,
  `zip` varchar(10) NOT NULL,
  `city` varchar(50) NOT NULL,
  `phone` varchar(20) DEFAULT NULL,
  `fax` varchar(20) DEFAULT NULL,
  `mail` varchar(255) DEFAULT NULL,
  `url` varchar(65) DEFAULT NULL,
  `update_date` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `create_date` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `unique` (`id_subscrib`,`company`,`address1`,`address2`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

ALTER TABLE `dat_customs`
  ADD CONSTRAINT `dat_customs_ibfk_1` FOREIGN KEY (`id_subscrib`) REFERENCES `subscribers` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;

Définition de la table lst_filters:

CREATE TABLE IF NOT EXISTS `lst_filters` (
  `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `id_subscrib` int(10) UNSIGNED NOT NULL,
  `text` varchar(25) NOT NULL,
  `ordering` int(2) DEFAULT NULL,
  `create_date` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE KEY `text` (`id_subscrib`,`text`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

ALTER TABLE `lst_filters`
  ADD CONSTRAINT `lst_filters_ibfk_1` FOREIGN KEY (`id_subscrib`) REFERENCES `subscribers` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;

-
Edité par jsuis 10 juillet 2019 à 10:11:46

id est la clé primaire de lst_filters, donc ta condition f.id = 10 ne peut concerner au mieux qu'une seule ligne.

jsuis a écrit:

Dans la clause WHERE f.id_subscrib=3 AND f.id=10, le deuxième terme n'est pas pris en compte.

Qu'est-ce que tu entends par "pas pris en compte" ?

• il te renvoie une ligne avec un f.id différent de 10 ? (ça m'étonnerait...)
• il te renvoie une ligne alors que tu pensais qu'il ne devrait rien renvoyer ?
• il ne te renvoie aucune ligne alors que tu pensais qu'il te renverrait quelque chose ?

Bonjour,

jsuis a écrit:

la requête ci-dessus donne le même résultat que celle-ci

Pour moi c'est juste une question de données ... N'est-il pas possible que le suscriber 3 ait tous ses customs liés au filtre 10 ?

Le meilleur moyen de vérifier c'est de faire :

SELECT c.id AS custom, f.id AS filter
FROM
	dat_customs c
		INNER JOIN lst_filters f
			ON c.id_subscrib=f.id_subscrib
WHERE f.id_subscrib = 3
ORDER BY f.id

Si toutes les lignes ont f.id = 10 tu as ta réponse ...

Après, la requête me paraît bizarre, custom et filter ne sont pas directement lié, puisque tu passes par suscriber. Avec ce modèle, un suscriber peut avoir plusieurs customs et plusieurs filters, donc ta jointure est plus qu'aléatoire et va retourner plus ou moins n'importe quoi ...

Merci pour vos réponses. Elles m'ont mis sur la voie. J'ai fait une confusion. lst_filters est une liste des filtres applicables, lst_customs est la liste des clients. Il manquait une table associative dat_filters qui associe les filtres applicables à chaque client.

Après essais tout fonctionne.

-
Edité par jsuis 10 juillet 2019 à 17:12:09