[Résolu] Comportement SQL

[dardadax]

Salut à tous,

Si je fais une jointure avec 2 bases non reliées dans leur schéma d'ensemble(ex : 2 tables de 2 bases différentes), avec comme lien de jointure , normalement si les bases sont comme suit (en structure) :

base DB :
table Analyse (id_analyse, id_lieu, id_temps, et des champs non clés)

base DWH :
table Question ( pk_question, id_question, id_produit, id_analyse, id_lieu, id_commentaire, valeur_rep)


et ce, sans produit cartésien non ?


Requête :

Sélectionner - Agrandir / Réduire

SELECT 

      a.PK_QUESTION

      ,a.ID_QUESTION

      ,a.ID_PRODUIT

      ,a.ID_LIEU

      ,b.ID_ANALYSE

      ,[champs non ID]

  FROM IDWH.dbo.[QUESTION] AS a LEFT OUTER JOIN DB.dbo.ANALYSE AS b ON a.ID_LIEU = b.ID_LIEU

Parce que MS SQL 2k5 me retourne un beau produit cartésien de 47715 lignes au lieu de mes 8000 lignes de ma table de question...
Petite info : une analyse possède plusieurs questions, une question est liée à une seule analyse (id_question peut apparaître plusieurs fois cependant : pk_question permet de dissocier les id_questions des analyses)
pour un même lieu, j'ai plusieurs analyses, chaque analyse ayant les mêmes questions (différentes selon les lieux)
Suite à mes recherches, j'ai viré les champs vides (remplacé par -1), sans effet cependant...


j'ai essayé tout : cross join, right outer join, inner join, full outer join ! toujours le même résultat...

C'est un bug MS SQL ou un comportement que je ne maîtrise pas ?(qui sait ^^)

Au passage : j'arrive aussi à avoir en jointure externe gauche des résultats type : 833 gauche, 47 715 droite, jointure externe gauche, résultat 4000
c'est surprenant...

Edit by Troll : Supression du "Salut troll, comment ça va ?" fais attention à tes copier / coller

[Troll]

Hum étrange en effet...

Tu pourrais, sauf si ça contient des données sensibles, faire un exports des tables en question dans un fichier .sql et l'héberger ? On pourrait mieux t'aider ^^

J'ai du mal à saisir, tu dis que id_question peut apparaître plusieurs fois...

Au final, il n'y a aucun champs qui est unique (genre en auto_increment) dans ta table question ?

Et dans ta table ANALYSE ?

Le but de ta requête c'est de faire quoi ?

[dardadax]

Salut !
merci pour ta réponse !

J'ai un champs en auto increment dans ma table question effectivement (le pk_question)
ce pk_question existe car le id_question n'est pas unique.
Id_analyse est aussi en auto increment dans la table de prod.
En gros ça donne : 1 id réponse fait allusion à une question, répétée au minimum 1 fois par analyse.
1 analyse se fait sur un lieu unique.


c'est assez complexe mais disons que le schéma est comme suit :

Un projet, constitué de lieux sur lesquels ont lieu des analyses.
Ces analyses sont en fait un ensemble de questions auxquelles on apporte des réponses plusieurs fois.(une série de réponse = 1 analyse)
ex : analyse semaine 1, analyse semaine 2, etc. pendant un mois pour un projet
Chaque question se voit associée 0, 1 ou plusieurs produits. (question de gamme de produit type ptit dej chez nestlé, produit spécifique type michoko ou générale type animation de promotion réalisée, les animateurs qui font la pub plus ou moins bien lol)


J'ai trouvé une partie de la solution : si ça marche pour la base de prod, alors on fait les jointures sur la base de prod...c'est bête mais ça marche -_-'
j'ai rajouté plein de champs dans la table question du DWH directement lors de son remplissage via la base de prod (id_analyse et tout champs intéressant)
Il ne me reste plus qu'à modifier les photos qui aident aux réponses...en théorie on ne devait pas avoir plusieurs photos par lieu et par analyse, sauf que...ils ne devaient pas être au courant. (donc nouvelle table de dimension pour le DWH si le client veut garder des infos sur ces photos id_photo unique, pk_question multiple, et c'est parti... ^^)

C'est drôle parce que les spécifications changent assez souvent lol. Et comme il n'y a pas de cahier des charges officiel parce que les intervenants client et presta originels sont tous partis, bah personne ne sait vraiment ce qu'il fallait faire de spécial ^^ (donc rajout ou suppression de fonctionnalités, parfois des mêmes, du jour au lendemain lol)
Je l'aurai un jour, je l'aurai (cette définition des besoins complète, stable et validée ^^)

Quand tu parles de mettre en ligne en export sql, tu parles des fichiers .bak de sauvegarde/restoration ? ou du code de création des tables ?

[Troll]

Salut Dardadax,

Je dois avouer qu'il est difficile de s'intégrer entièrement dans l'esprit du projet si tu ne réponds pas à ceci :

Citation :Le but de ta requête c'est de faire quoi ?

Et sans avoir un support sous la main, donc en réponse à :

Citation :Quand tu parles de mettre en ligne en export sql, tu parles des fichiers .bak de sauvegarde/restoration ? ou du code de création des tables ?

Je répondrai : le code de création (SQL) des tables. Avec le code d'insertion des données (plus facile pour travailler) à moins qu'il ne faille pas les divulguer, auquel cas tu ne mettras que le code de création des tables...

[TotofTeam]

salut, à vue d'oeil c'est clairement un problème d'analyse.

Sans cahier des charges et sans un plan détaillé de ta structure, il va te et nous paraitre difficile de trouver l'erreur dans ta jointure (unique ?) .

:|

[dardadax]

Hello !

C'est bizarre j'étais sûr d'avoir répondu au message de troll

en fait j'ai contourné le problème -_-" si ça marche dans la base de production mais pas dans la base du datawarehouse, alors on rajoute ce qu'il faut...
en insérant l'ID de l'analyse, tout marche niquel...

par contre je ne vois toujours pas comment avoir le code d'insertion des données (sous SQL server on peut avoir ça ? )

Je crois que l'on devrait interdire aux clients de supprimer leurs données...ça évite les problèmes de hierarchie lol

[Troll]

Salut,


Qu'est-ce que tu appelles "avoir le code d'insertion des données " au juste ?

[dardadax]

je ne faisais que reprendre ton discours ^^

Troll a écrit :
Je répondrai : le code de création (SQL) des tables. Avec le code d'insertion des données (plus facile pour travailler) à moins qu'il ne faille pas les divulguer, auquel cas tu ne mettras que le code de création des tables...

[Troll]

dardadax a écrit :je ne faisais que reprendre ton discours ^^

Troll a écrit :
Je répondrai : le code de création (SQL) des tables. Avec le code d'insertion des données (plus facile pour travailler) à moins qu'il ne faille pas les divulguer, auquel cas tu ne mettras que le code de création des tables...

Salut,


Bah... tu fais un export O_o

[dardadax]

pour SQL Server on peut exporter effectivement, mais en fichier plat ou excel, et autres variantes (fournisseurs oledb, etc.) mais nulle trace de scripts d'insertion des données ^^ j'ai raté quelque chose ?

autant fournir le .bak directement qui permet de restaurer la base