Bonjour à tous,

Le titre du sujet n'est pas très clair, mais j'espère que l'exemple qui va suivre le sera suffisamment : 

Imaginons une base de données contenant 3 tables : 

     Individus (id_individu)

     Transactions (id_transaction, id_individu, NombreAchat, NombreVente)

     LieuTransaction (id_lieuTransaction, id_transaction, villeAchat, villeVente )

Chaque individus va réaliser des achats uniquement OU des ventes uniquement. Un même individu n'aura jamais une valeur supérieure à 0 à la fois dans "NombreAchat" et "NombreVente". Et un individu réalisera forcément au moins 1 achat ou 1 vente

J'essaie de créer une requête qui me permettrait d'obtenir, pour chaque individu, la ville dans laquelle il a réalisé ses achats ou ses ventes : 

Mais le champs "Ville" doit à la fois contenir les valeurs des champs "villeAchat" et "villeVente", selon si l'individu a fait des achats ou des ventes.

Et c'est cette "dualité" que je n'arrive pas à écrire sous forme de requête. J'arrive à obtenir un champs "Ville" qui va contenir toutes les "villeAchat" ou bien toutes les "villeVente", mais je n'arrive pas à joindre ces deux informations dans le même champs. 

Je n'arrive pas à formuler en SQL :

Si pour un individu donné "NombreAchat" > 0, le champs Ville contiendra, pour cet individu, la valeur du champs "villeAchat"

Si pour un individu donné "NombreAchat" = 0, le champs Ville contiendra, pour cet individu, la valeur du champs "villeVente"

Merci d'avance pour votre aide

-
Edité par Luffygaya 6 janvier 2020 à 10:57:39

Bonjour,

Si les achats et les ventes sont des choses différentes mais ayant les mêmes données, pourquoi ne pas simplement donner un type à chaque transaction (Achat ou Vente), et ne saisir qu'une seule fois les données ville et nombre ?

Au final le modèle serait :

• individu ( id_individu [pk], etc. )
• transaction ( id_transaction [pk], id_individu [fk], type, nombre )
• lieu ( id_lieu [pk], id_transaction [fk], ville )

La colonne "type" vaudrait A ou V par exemple, ou 1 ou 2, peu importe ...

Cette modélisation supprime ton problème de départ ...

Oui, cela résoudrait mon problème, mais je n'ai pas la main sur la structure des bases de données que j'utilise.

Les modèles de ces bases de données ont été établis il y a un bon moment déjà (plusieurs années je pense). Et puis l'exemple que j'ai donné reste simple et fictif, bien que sa structure soit semblable à la base de données réelle que j'utilise. Ma base de données réelle est plus compliquée, avec plusieurs jointures à faire entre la table de départ ("individu" par exemple) et celle d'arrivée ("ville" par exemple). Mais le problème reste similaire à cet exemple fictif.

Et puis cela me permet d'améliorer mes connaissances en SQL. Tu m'avais déjà donné un coup de main sur un problème que je rencontrais il y a quelques jours concernant une requête avec plusieurs jointures, et du coup cela me permet de m'en sortir lorsque je retombe sur un cas similaire.

Luffygaya a écrit:

Si pour un individu donné "NombreAchat" > 0, le champs Ville contiendra, pour cet individu, la valeur du champs "villeAchat"

Si pour un individu donné "NombreAchat" = 0, le champs Ville contiendra, pour cet individu, la valeur du champs "villeVente"

C'est pourtant bien comme cela qu'il faut dire les choses ...

SELECT
	T.id_transaction,
	I.id_individu,
	L.id_lieuTransaction,
	IF( T.NombreAchat = 0 , "Vente", "Achat" ) AS type_transaction,
	IF( T.NombreAchat = 0 , NombreVente, NombreAchat ) AS nombre,
	IF( T.NombreAchat = 0 , villeVente, villeAchat ) AS ville
FROM
	Transactions T
		INNER JOIN LieuTransaction L
			ON T.id_transaction = L.id_transaction
		INNER JOIN Individus I
			ON T.id_individu = I.id_individu

Sinon, pour revenir sur ce modèle imposé, dans ce contexte, une transaction peut avoir plusieurs lieux associés, donc potentiellement plusieurs lignes seront retournées dans ta requête pour une même transaction ... Selon moi c'est id_lieu qui devrait être dans la table transaction et non le contraire ...

Je persiste donc à dire que le modèle est mauvais, et que la dette technique de ce projet va s'accumuler si vous ne corriger pas le modèle ...