Bonjour à tout le monde,

J'ai un problème sur un requête SQL pour pouvoir récupérer des données dans 3 tables.

Voici mes tables: 

Ma requête doit me permettre d'afficher des publications comme sur un réseau sociaux, je cherche donc à récupérer les boots ( équivalent d'un tweet ) des abonnements ainsi que l'utilisateur qui la crée mais à ça je voudrais aussi récupérer les reboots ( équivalent d'un retweet) des abonnements et ce de l'utilisateur qui le crée.

J'ai donc fait une requête mais ma requête ne fonctionne pas car elle ne me r'envoie pas les reboots.

Ma requête: 

SELECT boot.id_boot AS "idB", media_boot AS "medB", contenu_boot AS "ctnB", date_boot AS "dtB" FROM `abonnement` 
								INNER JOIN utilisateur ON abonnement.id_abonnement = utilisateur.id_utilisateur
								INNER JOIN boot ON boot.id_utilisateur = utilisateur.id_utilisateur 

LEFT JOIN reboot ON utilisateur.id_utilisateur = reboot.id_utilisateur
								WHERE abonnement.id_utilisateur = :id OR boot.id_utilisateur = :id OR reboot.id_utilisateur = :id
GROUP BY boot.id_boot DESC

J'ai déjà aussi essayer de faire avec trois INNER JOIN mais ça ne fonctionne pas non plus.
Je pense que le problème vient des jointures mais je ne trouve pas comment faire pour résoudre mon problème.

Merci d'avance pour votre temps.

Bonjour,

Airouane a écrit:

je cherche donc à récupérer les boots ( équivalent d'un tweet ) des abonnements ainsi que l'utilisateur qui la crée mais à ça je voudrais aussi récupérer les reboots ( équivalent d'un retweet ) des abonnements et ce de l'utilisateur qui le crée

C'est quoi un abonnement ? Je ne comprends pas comment cela fonctionne ...

Après il y a la question des cardinalités ... un boot pouvant avoir plusieurs reboots, tu vas avoir des doublons, comment vois-tu les choses ?

Pourrais-tu nous donner un exemple de données (abonnement, boots et reboots) et le résultat que tu souhaiterais obtenir ?

Par ailleurs, la colonne id_boot dans la table aimer ne sert à rien puisque cet id se déduit de l'id_commentaire ...

Merci pour ta réponse.

Un utilisateur peut s'abonner à un autre utilisateur (abonnement).

J'ai crée une table reboot justement pour cela car on peut avoir plusieurs reboot d'un boot.

Quand je fais cette requête: 

SELECT utilisateur.id_utilisateur,reboot.id_reboot, boot.id_boot AS "idB", media_boot AS "medB", contenu_boot AS "ctnB", date_boot AS "dtB" FROM `abonnement` 
INNER JOIN utilisateur ON abonnement.id_abonnement = utilisateur.id_utilisateur 
INNER JOIN boot ON boot.id_utilisateur = utilisateur.id_utilisateur 
LEFT JOIN reboot ON utilisateur.id_utilisateur = reboot.id_utilisateur 
WHERE abonnement.id_utilisateur = 12 OR boot.id_utilisateur = 12 OR reboot.id_utilisateur = 12 GROUP BY boot.id_boot DESC

Je récupère ca

Sauf que dans ma table reboot 

id_reboot n'est pas du tout avec le bon id_boot alors que je voudrais récupérer les boot et les reboots bien distinctement.

Et je ne vois pas comment faire 

Merci pour ta réponse  

Airouane a écrit:

Un utilisateur peut s'abonner à un autre utilisateur (abonnement)

Ok, mais avec ton modèle tu ne sais pas quel utilisateur s'est abonné (ou tu ne sais pas à qui il s'est abonné ...), donc tu ne peux pas retrouver les bons abonnements ...

Selon moi ton modèle devrait être au minimum celui-ci :

utilisateur ( id_utilisateur [pk], nom, prenom, ... ) pour enregistrer tous tes utilisateurs

• abonnement ( id_utilisateur_suivi [pk][fk], id_utilisateur_demande [pk][fk] ) ici une clé primaire composée de 2 id utilisateurs, l'un pour dire qui s'abonne l'autre pour dire à qui il s'abonne
• boot ( id_boot [pk], id_utilisateur [fk], ... ) ici l'id utilisateur est l'id de celui qui crée le boot
• reboot ( id_reboot [pk], id_boot [fk], id_utilisateur [fk], ... ) ici l'id utilisateur est l'id de celui qui crée le reboot
• commentaire ( id_commentaire [pk], id_boot [fk], id_utilisateur [fk], ... ) ici l'id utilisateur est l'id celui qui crée le commentaire
• aimer ( id_commentaire [pk][fk], id_utilisateur [pk][fk] ) ici une clé primaire composée pour lier un utilisateur à un commentaire aimé
• sauvegarder ( id_boot [pk][fk], id_utilisateur [pk][fk] ) ici une clé primaire composée pour lier un utilisateur à un boot "favori"

Airouane a écrit:

je cherche donc à récupérer les boots ( équivalent d'un tweet ) des abonnements ainsi que l'utilisateur qui la crée mais à ça je voudrais aussi récupérer les reboots ( équivalent d'un retweet) des abonnements et ce de l'utilisateur qui le crée

Avec le modèle proposé, tu pars de la table abonnement puis tu remontes le fil jusqu'aux reboots ...

SELECT
	B.id_boot,
	B.date_boot,
	B.media_boot,
	B.contenu_boot,
	B.id_utilisateur AS "id_utilisateur_boot",
	UB.pseudo AS "pseudo_boot",
	R.id_reboot,
	R.date_reboot,
	R.contenu_reboot,
	UR.id_utilisateur AS "id_utilisateur_reboot",
	UR.pseudo AS "pseudo_reboot"
FROM
	-- On part des abonnements
	abonnement A
	
		-- On prend tous les boots créés par les utilisateurs abonnés
		INNER JOIN boot B
			ON A.id_utilisateur_suivi = B.id_utilisateur
			
		-- On retrouve les données des utilisateurs booters
		INNER JOIN utilisateur UB
			ON B.id_utilisateur = U.id_utilisateur
			
		-- On récupère les reboots si il y en a
		LEFT JOIN reboot R
			ON B.id_boot = R.id_boot
			
		-- On récupère les données des utilisateurs rebooters
		LEFT JOIN utilisateur UR
			ON R.id_utilisateur = UR.id_utilisateur

WHERE
	-- On ne prend que les abonnements de utilisateur connecté
	A.id_utilisateur_demande = 'id utilisateur connecté'

Pour moi tu es obligé de modifier ta table abonnement pour lier un utilisateur aux utilisateurs qu'il veut suivre ...

Merci pour ta réponse.

Il faut que je crée les tables UR et UB ducoup ?

UR et UB sont des alias, de simples noms de remplacement pour faciliter l'écriture de la requête. Ces deux alias pointent sur la même table, la table utilisateur qui existe déjà.

Par contre c'est la structure de la table abonnement qu'il faudrait revoir, selon moi, en fonction des remarques faites plus haut :

Benzouye a écrit:

avec ton modèle tu ne sais pas quel utilisateur s'est abonné (ou tu ne sais pas à qui il s'est abonné ...)

Benzouye a écrit:

• abonnement ( id_utilisateur_suivi [pk][fk], id_utilisateur_demande [pk][fk] ) ici une clé primaire composée de 2 id utilisateurs, l'un pour dire qui s'abonne l'autre pour dire à qui il s'abonne

Benzouye a écrit:

Pour moi tu es obligé de modifier ta table abonnement pour lier un utilisateur aux utilisateurs qu'il veut suivre ...

-
Edité par Benzouye 7 novembre 2019 à 9:24:47

Cela dépend ... Sur mon poste en développement j'ai MySQL 8 et également MariaDB 10.4.6

Sur certains serveurs hébergés j'utilise encore MySQL 5.7 et 5.5 voire même 5.1.