Discussion :

[bqyben]

Bonjour,

alors mon problème n'est pas très compliqué je l'expose :

Je refond la base de donnée d'une application, pour cette refonte, je me dois de récupérer les anciennes données.. jusque là pas de problème..

Il s'agit d'une application de hotline, j'ai hotline_appel qui se trouve être mon ancienne table, et appel qui se doit de prendre la relève, hotline_appel contient un champs "id_ext_mag" qui est l'id du tuple magasin de la table magasin.
Ce qu'il se passe c'est que pour ma nouvelle table, je ne veux pas l'id du magasin mais son matricule, donc je dois le piocher dans la bonne table grâce à l'id que me fournis l'ancienne..

Voici la requête que j'ai commencé à créer :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
INSERT INTO hotlinev2.appel(appel_date,appel_heure,appelant,cloture_date,cloture_heure,appel_mag) 
SELECT 
hotline.hotline_appel.date_appel AS appel_date, 
hotline.hotline_appel.heure_appel AS appel_heure,
hotline.hotline_appel.contact AS appelant,
hotline.hotline_appel.date_depanne AS cloture_date,
hotline.hotline_appel.heure_depanne AS cloture_heure,
(SELECT i1.num_strate FROM hotline.mag AS i1, hotline.hotline_appel AS i2 WHERE i1.id_mag = i2.id_ext_mag) AS appel_mag

FROM hotline.hotline_appel

Le champs en gras étant celui qui m’intéresse, vous l'aurez compris en tant qu'expert de SGBD, que j’espère vous êtes, cette sous-requête me renvois forcement la liste intégrale des données correspondantes alors que je voudrais qu'elle me renvoie le matricule(num_strate) du magasin correspondant à l'enregistrement.

Est-ce une condition que je dois rajouter ou autre ? j'aimerai une piste et reste disponible pour toute information complémentaire.

PS : je n'ai pas mis la structure des tables car le soucis me semble assez explicite mais si il la faut, je la post dans l'immédiat.

[CinePhil]

Je refond la base de donnée d'une application,

Ca peut être utile, à condition d'améliorer la structure de la BDD.

Ce qu'il se passe c'est que pour ma nouvelle table, je ne veux pas l'id du magasin mais son matricule, donc je dois le piocher dans la bonne table grâce à l'id que me fournis l'ancienne..

Et là vous détériorez le modèle au lieu de l'améliorer !

Vous êtes sûr d'avoir les compétences pour faire ça ?

Il vaut mieux une clé étrangère référençant un identifiant entier qu'un matricule alphanumérique.

[bqyben]

Les compétences pour faire ça ? bon ça va je travail sur une copie de la base pas d'inquietude, de plus je ne suis qu'un vulgaire stagiaire

La raison de mon geste irresponsable est que la liste des magasins à évolué depuis, et celle de ma nouvelle base ne correspond plus à l'ancienne, du fait, les id que je récupérerai ne seraient pas cohérents... l'id du magasin 280 de l'ancienne table n'est pas forcement le même que celui présent dans la table magasin de ma nouvelle base, alors que si on les compare sur leur matricule, c'est le cas

bon j'ai modifié ma requête de cette façon :

Code :

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

(SELECT * FROM (SELECT i1.num_strate FROM hotline.mag AS i1, hotline.hotline_appel AS i2 WHERE i1.id_mag = i2.id_ext_mag) AS nums WHERE nums.num_strate = hotline.hotline_appel.id_ext_mag) AS appel_mag

et ça mouline depuis 5min (faut dire que ya un paquet d'enregistrement)..

Pourriez vous me dire si je me suis royalement planté et que je vais attendre jusque ce soir pour comprendre que j'ai crée une boucle infini ou un truc du genre ? ou si je marche sur les bonnes traces ?

[punkoff]

C'est pas terrible comme requête.

utilisez plutot une jointure (en version normalisé pendant que vous y êtes).

http://sqlpro.developpez.com/cours/sqlaz/jointures/

[bqyben]

Effectivement et merci PunkOff,

au lieu de faire ma jointure à l'intérieur même de la requête je l'ai simplement déplacé sur ma "vue" de travail et c'est tout de suite plus efficace

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
INSERT INTO hotlinev2.appel(appel_date,appel_heure,appelant,cloture_date,cloture_heure,appel_mag) 
SELECT 
hotline.hotline_appel.date_appel AS appel_date, 
hotline.hotline_appel.heure_appel AS appel_heure,
hotline.hotline_appel.contact AS appelant,
hotline.hotline_appel.date_depanne AS cloture_date,
hotline.hotline_appel.heure_depanne AS cloture_heure,
hotline.mag.num_strate AS appel_mag
 
FROM hotline.hotline_appel, hotline.mag WHERE hotline.hotline_appel.id_ext_mag = hotline.mag.id_mag

Merci à vous !

PS : et pour ma défense CinePhil, je corrige l'erreur que tu me signal sur un autre champ ou le nom de l’opérateur est enregistré au lieu de sa clé ! Je déplace le problème la ou il peu s’avérer nécessaire

[CinePhil]

La raison de mon geste irresponsable est que la liste des magasins à évolué depuis, et celle de ma nouvelle base ne correspond plus à l'ancienne, du fait, les id que je récupérerai ne seraient pas cohérents... l'id du magasin 280 de l'ancienne table n'est pas forcement le même que celui présent dans la table magasin de ma nouvelle base, alors que si on les compare sur leur matricule, c'est le cas

Donc tu as, dans ta nouvelle BDD, une table des magasins ?
J'ose espérer que la clé primaire de cette table est un entier auto-incrémenté ?
Les autres informations du magasin étant importées de l'ancienne table de l'ancienne BDD ?

Donc il faut récupérer le nouvel identifiant correspondant au magasin X dans la nouvelle BDD pour l'utiliser en tant que clé étrangère.

Si num_strate est un code alphanumérique unique pour chaque magasin, donc une clé candidate (ou alternative), il est facile de récupérer le nouvel id_magasin correspondant au num_strate.

Code :

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

1
2
3
4
5
INSERT INTO hotlinev2.appel(appel_date, appel_heure, appelant, cloture_date, cloture_heure, appel_mag) 
SELECT ha.date_appe, ha.heure_appel, ha.contact, ha.date_depanne, ha.heure_depanne, m2.id_mag
FROM hotline.hotline_appel ha
INNER JOIN hotline.mag m1 ON m1.id_mag = ha.id_ext_mag
	INNER JOIN hotlinev2.mag m2 ON m2.num_strate = m1.num_strate

Au passage, remarque l'écriture normalisée depuis 20 ans pour les jointures et l'utilisation des alias.

[bqyben]

Hello,

Donc tu as, dans ta nouvelle BDD, une table des magasins ?
J'ose espérer que la clé primaire de cette table est un entier auto-incrémenté ?
Les autres informations du magasin étant importées de l'ancienne table de l'ancienne BDD ?

Oui j'ai dans ma nouvelle BDD une table des magasins, et c'est là que je risque de me faire flame, non j'ai opté pour le matricule du magasin comme clé primaire..
Est-ce si grave que l'ID de ma table ne soit pas un entier auto_increment ?
Toutes mes tables ont cet ID classique sauf ma table magasin, les magasin ont un matricule unique et il s'agit littéralement de leur identifiant..

Nop je récupère les magasin dans un fichier Excel à jour (donc pas d'identifiant) car la liste a beaucoup changé depuis, c'est tout ce cheminement qui m’amène a penser qu'un id supplémentaire serait superficiel.. Je vois bien que je viole une règle mais pour le coup je ne vois pas quel impact négatif ça pourrait avoir.

Edit : Effectivement c'est nettement plus propre comme requête mais on manque cruellement de cours sur les SGBD dans ma formation.. j'ai des restes de BTS mais on est pas allé très loin..
Edit2 : de plus je pioche dans de nombreux fichiers pour récupérer des infos a intégrer (comme les ip des machines du mag, etc..) et pareil je n'ai pas d'id mag, juste leur matricule lors de l'intégration, je pourrait alors faire mon intégration dans une table temporaire puis une requête du même type que celle dont j'avais besoin dans mon message d'origine pour les réinsérer dans la table définitive mais j'obtiendrai un résultat identique

Edit 3 : Ah je constate que ça fait l'objet d'un débat depuis longtemps !!
http://www.developpez.net/forums/d80...har-6-integer/
J'ai choisi mon camp et je resterai sur l'idée d'avoir le matricule en clé primaire car la table contient actuellement ~350 ligne et ne devrait pas dépasser les 500 d'ici 10 ans (à moins que..) donc niveau performance ça ne devrait pas avoir beaucoup d'impact..

[CinePhil]

Est-ce si grave que l'ID de ma table ne soit pas un entier auto_increment ?

À lire.

J'ai choisi mon camp et je resterai sur l'idée d'avoir le matricule en clé primaire car la table contient actuellement ~350 ligne et ne devrait pas dépasser les 500 d'ici 10 ans (à moins que..) donc niveau performance ça ne devrait pas avoir beaucoup d'impact..

Et malgré ce que tu as lu dans cette discussion tu persistes avec une clé primaire alphanumérique ?