Discussion :

[iberserk]

D'un autres côté vous estimez que même si le GPS n'est pas connu il convient d'ajouter la ligne, soit mais vous perdez alors la source de l'information (nom du GPS) pourquoi ne pas automatiser l'ajout préalable du GPS inconnu dans la table des GPS avant de faire un insert avec INNER JOIN?

J'ai ce même mécanisme sur une table de trace des actions sur un site d'EBUSINESS avec l'information navigateur+version navigateur qui peut de la même manière ne pas être connu.

Pour éviter NULL j'ai donc un mécanisme ajoutant tout navigateur actuellement inconnu dans la base de données.


Message personnel: COME ON VALE ROSSI!

[olibara]

Merci Ibersek

Mais là il y a quelque chose que ne ne comprends pas ou que je ne connais pas
Qu'entends tu par mettre le where ou niveau de la jointure ?

Je ne savais meme pas que c'était possible : quelle est la syntaxe ?

Voici ci-dessous un exemple reduit avec l'OUTER Join qui emule le resultat avec un GPS Inconnu

Le where s'applique sur le SELECT et non pas sur la jointure

Par ailleurs pour répondre a ta suggestion : OUI une insertion automatique d'un GPS inconnu serait possible
Toutefois pour diverses raison j'ai opté pour le maintien d'une Information NULL qui est traitée par l'application Business qui signale ces information incomplete et il appartient au gestionnaire de flotte de faire les ajout nécessaires via l'application ad-hoc
L'ajout automatique du GPS n'apporterait rien parce que cette situation implique d'autres intervention purement humaines

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
DECLARE
  	@latitude float,
    @longitude float,
    @Date DateTime,
	@speed float,
	@imei varchar(12),
	@IOSTAT TinyInt
 
	SET @IMEI='01AF0003'
 
   SELECT
  	@latitude,
    @longitude,
    @Date,
	@speed,
	@imei,
    V.ChauffeurPkid,
    @IOSTAT,
	V.deviceID
    FROM dbo.Vehicle V  
    LEFT OUTER JOIN dbo.GPSDevice AS GPS ON GPS.pkid = V.DeviceID 
    WHERE GPS.DeviceSN = @Imei

[olibara]

Bonjour à tous

Je reste curieux et attentif de savoir s'il y a vraiment une meilleure solution qui produirait le meme résultat que sous-select

Le INNER JOIN ne donne pas le resultat attendu
Le OUTER JOIN non plus ... sous reserve de comprendre ce que Ibersek entends par un "WHERE au niveau du JOIN" ce que jusquà présent je n'ai pas compris

[aieeeuuuuu]

Bonjour,

Je pense qu'Iberserk voulais simplement dire de déplacer la condition GPS.DeviceSN = @imei depuis le WHERE vers ON de la condition de jointure.

Mais je pense en effet que cela ne suffira pas, si le GPS n'est pas enregistré.
Je me pose toutefois la même question : quel est l’intérêt de stocker un valeur qui n'est pas exploitable ? Si j'ai bien suivi, vous stockerez dans votre table une latitude et une longitude, mais qui ne seront rattachées à rien...

Personnellement, votre sous requete ne me choque pas outre mesure, surtout que vous ne récupérez qu'une seule colonne, mais d'après moi, cela dénote tout de même un défaut de modélisation. Il semble que vous soyez en train de suivre les chauffeurs, par leur GPS. votre partie du modèle concernant le rattachement entre les chauffeurs et le GPS devrait certainement être en sixième forme normale, afin de garder l'historique. Ansi, dans votre table GPSTrace, nul besoin de l'identifiant du chauffeur.
Mais tout ça n'est que supposition avec les informations dont nous disposons...

[iberserk]

Que tonnes ceci?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
SELECT
  	@latitude,
    @longitude,
    @Date,
	@speed,
	@imei,
    V.ChauffeurPkid,
    @IOSTAT,
	V.deviceID,
COUNT(*)
    FROM dbo.Vehicle V  
    LEFT OUTER JOIN dbo.GPSDevice AS GPS ON GPS.pkid = V.DeviceID AND GPS.DeviceSN @Imei
  GROUP BY V.deviceID

[aieeeuuuuu]

Que tonnes ceci?

A priori, je dirai autant de null qu'il y a de lignes dans la table véhicule puisque l'imei n'existe pas dans la table GPS...

[hmira]

D'après moi, une requête qui serait, en terme d'algébrisation, équivalente à la requête initiale fournie par olibara, et qui donnerait exactement les mêmes résultats serait la suivante :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
SELECT A.prm_latitude, A.prm_longitude, A.prm_Date, A.prm_speed, A.prm_imei, B.ChauffeurPkid        
FROM (  SELECT @latitude AS prm_latitude,
               @longitude AS prm_longitude,
               @Date AS prm_Date,
               @speed As prm_speed,
	           @imei  AS prm_imei
	   )  A  		 		  
OUTER APPLY  ( SELECT TOP(1) V.ChauffeurPkid 
               FROM vehicle V
               INNER JOIN GPSDevice GPS 
		ON GPS.pkid=V.DeviceID 
	      WHERE GPS.DeviceSN=A.prm_imei  ) B

PS : N'ayant pas de données significatives dans les tables afférentes, je ne peux en mesurer la pertinence. Même sur des tables vides, j'ai constaté, néanmoins une légère différence dans les plans d'exécution des 2 requêtes (requête Initiale d'olibara et la requête ci-dessus). Les 2 plans sont presques identiques, ils présentent toutefois des différences dans la préséance des opérations (Table Scan, Index Seek, Constant Scan, etc.).

A+

[iberserk]

A priori, je dirai autant de null qu'il y a de lignes dans la table véhicule puisque l'imei n'existe pas dans la table GPS...

oups je voulais mettre le prédicate dans le WHERE pas dans le ON

[hmira]

oups je voulais mettre le prédicate dans le WHERE pas dans le ON

Si vous déplacez le prédicat vers le WHERE, votre requête ne serait plus équivalente à la requête initiale de olibara et donc ne retournera pas forcément les mêmes résultats.

En effet, dès lors que la clause WHERE n'est vérifiée, votre requête ne ramènera aucun enregistrement et donc aucune lignes ne sera insérée dans la table GPSTRACE, contrairement à la requête initiale qui elle insère systématiquement une ligne quitte à avoir la colonne Tour à NULL.

Donc votre requête n'est pas algébriquement équivalente à la requête initiale. En d'autres termes, elle ne générera pas le même arbre algébrique, et donc ne produira pas les mêmes résultats !

A+

[olibara]

Merci a tous

Merci pour tes remarques pertinentes Hmira tu a tout a fait raison
A choisir, ma requete initiale a l'avantage d'etre simple et finalement pas tres gourmande en ressource

Merci Ibersek d'avoir essayé de resoudre la quadrature du cercle mais on revient au meme point

En ce qui concerne l'enregistrement de trace liées a rien, ce n'est pas tout a fait vrai, j'enregistre toujours le numero unique du GPS (IMEI) qui sert de clef, et ce numero permettra dounc toujours a l'aplication de visualiser la trace liée a ce GPS et le cas ecéant lier cette clef aux information manquantes qui peuvent etre liée apres coup

Et dans la réalité il peut y avoir de situation ou le Numero du GPS ne sera révellé que lors de l'apparition d'une trace !

[iberserk]

En effet, dès lors que la clause WHERE n'est vérifiée, votre requête ne ramènera aucun enregistrement et donc aucune lignes ne sera insérée dans la table GPSTRACE, contrairement à la requête initiale qui elle insère systématiquement une ligne quitte à avoir la colonne Tour à NULL.

JE ne peux qu'admettre mon erreur... voilà ce qui se passe quand on réponds à la hates et sans vérifier sous ce bon vieux SSMS