[MySQL/ SQL] Requête INSERT
Résolu
Sandriine
Messages postés
1255
Date d'inscription
Statut
Membre
Dernière intervention
-
Sandriine Messages postés 1255 Date d'inscription Statut Membre Dernière intervention -
Sandriine Messages postés 1255 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
J'ai 3 tables :
IMPRIMANTE (num, ref_modele)
LOCALISER (#num_impr, #ref_secteur)
SECTEUR (ref_secteur, libelle_secteur)
LOCALISER est donc une association entre imprimante et secteur.
Comment doit se passer l'ajout d'une imprimante? Il faut mettre à jour également la table localiser, mais je ne sais pas comment faire.
Une requête INSERT pour la table IMPRIMANTE et une autre pour la table LOCALISER? Une seule requête pour la table IMPRIMANTE?
Je précise que dans PhpMyAdmin, mes tables sont de types InnoDB donc je devrais pouvoir gérer les relations...
Merci de m'aider!
Cordialement,
Sandrine
J'ai 3 tables :
IMPRIMANTE (num, ref_modele)
LOCALISER (#num_impr, #ref_secteur)
SECTEUR (ref_secteur, libelle_secteur)
LOCALISER est donc une association entre imprimante et secteur.
Comment doit se passer l'ajout d'une imprimante? Il faut mettre à jour également la table localiser, mais je ne sais pas comment faire.
Une requête INSERT pour la table IMPRIMANTE et une autre pour la table LOCALISER? Une seule requête pour la table IMPRIMANTE?
Je précise que dans PhpMyAdmin, mes tables sont de types InnoDB donc je devrais pouvoir gérer les relations...
Merci de m'aider!
Cordialement,
Sandrine
A voir également:
- [MySQL/ SQL] Requête INSERT
- Touche insert - Guide
- Disk boot failure insert system disk and press enter - Guide
- Mysql community server - Télécharger - Bases de données
- Logiciel sql - Télécharger - Bases de données
- Mysql error in file: /engine/classes/mysql.php at line 53 ✓ - Forum Réseaux sociaux
25 réponses
Vous insérez dans la table imprimante, puis vous insérer dans la table secteur et enfin vous faites une insertion dans la table localiser avec les deux valeurs qui vont bien, c'est à dire la valeur de "num" que vous avez mise en première insertion et la valeur de "ref_secteur" mise en deuxième insertion
Salut,
Pour moi une insertion dans imprimante et une dans localisation.
Par contre je ne comprend pas trop la raison d'être de la table localisation.
Pourquoi par seulement IMPRIMANTE (num, ref_modele,#ref_secteur) ? sauf si une imprimante est 'associable' a plusieurs secteurs simultanément.
Pour moi une insertion dans imprimante et une dans localisation.
Par contre je ne comprend pas trop la raison d'être de la table localisation.
Pourquoi par seulement IMPRIMANTE (num, ref_modele,#ref_secteur) ? sauf si une imprimante est 'associable' a plusieurs secteurs simultanément.
Oui voilà une imprimante peut être assimilée à 2 secteurs. Ca paraît étrange mais si elle se trouve dans un couloir entre 2 secteurs, il faut qu'on puisse la retrouver dans les 2 secteurs par exemple...
Merci en tout cas à vous, mon problème est résolu.
Par contre j'ai un autre soucis....
Je voudrais rajouter un "détail de secteur" concernant une imprimante. C'est à dire que je voudrais savoir plus précisément où l'imprimante est située dans le secteur.
Exemple : l'imprimante X est dans le secteur A, plus précisément à l'endroit A1.
La table DETAIL serait donc rattachée à la table SECTEUR, mais dois-je la rattacher à la table IMPRIMANTE ?
Merci en tout cas à vous, mon problème est résolu.
Par contre j'ai un autre soucis....
Je voudrais rajouter un "détail de secteur" concernant une imprimante. C'est à dire que je voudrais savoir plus précisément où l'imprimante est située dans le secteur.
Exemple : l'imprimante X est dans le secteur A, plus précisément à l'endroit A1.
La table DETAIL serait donc rattachée à la table SECTEUR, mais dois-je la rattacher à la table IMPRIMANTE ?
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
D'accord donc tout se fait grâce aux jointures dans la requête SQL si j'ai bien compris.
Merci beaucoup à toi.
Merci beaucoup à toi.
Je reviens sur mon détail de secteur, je ne peux pas attribuer un détail de secteur à une imprimante.
Avec ma conception actuelle, j'attribue juste plusieurs détails de secteurs à un même secteur :
IMPRIMANTE (num, ref_modele)
LOCALISER (#num_impr, #ref_secteur)
SECTEUR (ref_secteur, libelle_secteur)
DETAILSECTEUR(Num, nom_detail,#ref_secteur)
Je pense qu'il me manque une clé étrangère, mais où ... ? -_-
Avec ma conception actuelle, j'attribue juste plusieurs détails de secteurs à un même secteur :
IMPRIMANTE (num, ref_modele)
LOCALISER (#num_impr, #ref_secteur)
SECTEUR (ref_secteur, libelle_secteur)
DETAILSECTEUR(Num, nom_detail,#ref_secteur)
Je pense qu'il me manque une clé étrangère, mais où ... ? -_-
Il faut que dans SECTEUR il y ait une clé étrangère vers DETAIL et non le contraire
malheureusement cela créer un problème de redondance pour ajouter plusieurs détails secteur à un seul secteur.
Je vous conseille de d'abord faire un schéma qui récapitule vos liens entre tables afin de savoir réellement ce dont vous avez besoin et non de rajouter des éléments au fur et à mesure.
malheureusement cela créer un problème de redondance pour ajouter plusieurs détails secteur à un seul secteur.
Je vous conseille de d'abord faire un schéma qui récapitule vos liens entre tables afin de savoir réellement ce dont vous avez besoin et non de rajouter des éléments au fur et à mesure.
Un SECTEUR peut avoir un ou plusieurs DETAIL
Un DETAIL appartient à un et un seul SECTEUR.
La règle est donc de mettre la clé étrangère dans DETAIL, non?
Un DETAIL appartient à un et un seul SECTEUR.
La règle est donc de mettre la clé étrangère dans DETAIL, non?
Désolé je n'ai pas compris là...
Tu pense qu'il faudrait que j'ajoute d'autres associations?
Quelle serait la conception adéquate pour pouvoir gérer le détail d'un secteur d'une imprimante?...
Tu pense qu'il faudrait que j'ajoute d'autres associations?
Quelle serait la conception adéquate pour pouvoir gérer le détail d'un secteur d'une imprimante?...
Bien résumons:
Une imprimante peut avoir plusieurs secteurs
Un secteur peut avoir plusieurs imprimantes
Un secteur peut avoir plusieurs détails secteur
Une imprimante a un seul détail secteur
est-ce que ces règles sont correctes, y'en a-t-il d'autres?
(c'était ma question même si elle n'était pas très bien formulée :) )
Une imprimante peut avoir plusieurs secteurs
Un secteur peut avoir plusieurs imprimantes
Un secteur peut avoir plusieurs détails secteur
Une imprimante a un seul détail secteur
est-ce que ces règles sont correctes, y'en a-t-il d'autres?
(c'était ma question même si elle n'était pas très bien formulée :) )
Non c'est tout ^^.
Bon en fait je pense avoir trouver : LOCALISER devient une asso ternaire avec reliées à elle : Imprimante, Secteur, et Détail Secteur.
Comme ça je pense pouvoir retrouver le détail secteur d'une imprimante...?
Bon en fait je pense avoir trouver : LOCALISER devient une asso ternaire avec reliées à elle : Imprimante, Secteur, et Détail Secteur.
Comme ça je pense pouvoir retrouver le détail secteur d'une imprimante...?
Tu peux me faire un schéma rapide de ce que tu viens de m'expliquer stp??
...Ce sujet me donne des sueurs froides -_-
...Ce sujet me donne des sueurs froides -_-
IMPRIMANTE (num, ref_modele)
LOCALISER (#num_impr, #ref_detailsecteur)
SECTEUR (ref_secteur, libelle_secteur)
DETAILSECTEUR(ref_detail, libelle_detail, #ref_sect)
comme tu vois un détail secteur n'ayant qu'un seul secteur, il suffit de donner à l'imprimante son détailsecteur pour qu'elle connaisse son secteur.
Exemple:
imprimante X, détailsecteur A1
et on sait que détailsecteur A appartient à secteur A
donc imprimante appartient à secteur A et plus exactement au détailsecteur A1
LOCALISER (#num_impr, #ref_detailsecteur)
SECTEUR (ref_secteur, libelle_secteur)
DETAILSECTEUR(ref_detail, libelle_detail, #ref_sect)
comme tu vois un détail secteur n'ayant qu'un seul secteur, il suffit de donner à l'imprimante son détailsecteur pour qu'elle connaisse son secteur.
Exemple:
imprimante X, détailsecteur A1
et on sait que détailsecteur A appartient à secteur A
donc imprimante appartient à secteur A et plus exactement au détailsecteur A1
J'ai fais comme ça, et ça à l'air de marcher ^^
Un grand merci à toi pour ta patience =D
Je reposterais si jamais je rencontre un soucis.
A+!!
Un grand merci à toi pour ta patience =D
Je reposterais si jamais je rencontre un soucis.
A+!!
Encore un petit soucis!
J'ai donc ces 3 tables :
IMPRIMANTE(num)
LOCALISER (num_impr, num_detail)
DETAILSECTEUR(num, nom_detail)
Une imprimante est localisée dans aucun ou plusieurs détails secteur,
Un détail secteur localise une ou plusieurs imprimantes.
Lorsque je veux ajouter une imprimante qui n'a pas de détail secteur, MySQL me renvoi une erreur puisqu'il faut absolument une valeure dans num_detail de la table LOCALISER.
Comment faire pour ajouter une imprimante qui n'a pas de détail secteur, sachant que j'ai mis detailsecteur comme entier, autoincrément ?
J'ai donc ces 3 tables :
IMPRIMANTE(num)
LOCALISER (num_impr, num_detail)
DETAILSECTEUR(num, nom_detail)
Une imprimante est localisée dans aucun ou plusieurs détails secteur,
Un détail secteur localise une ou plusieurs imprimantes.
Lorsque je veux ajouter une imprimante qui n'a pas de détail secteur, MySQL me renvoi une erreur puisqu'il faut absolument une valeure dans num_detail de la table LOCALISER.
Comment faire pour ajouter une imprimante qui n'a pas de détail secteur, sachant que j'ai mis detailsecteur comme entier, autoincrément ?
Et oui, mais dans ce cas là je ne peux pas faire en sorte qu'une imprimante n'ait pas de détail secteur ?
Oui je suis un peu bloquée par rapport à la conception qu'on a vu précédemment, qui me convenait très bien jusqu'à maintenant :
IMPRIMANTE (num, ref_modele)
LOCALISER (#num_impr, #ref_detailsecteur)
SECTEUR (ref_secteur, libelle_secteur)
DETAILSECTEUR(ref_detail, libelle_detail, #ref_sect)
En fait ça revient à dire qu'une imprimante est rattachée à un détail secteur qui appartient à un secteur. Alors que normalement elle est rattachée à un secteur.
IMPRIMANTE (num, ref_modele)
LOCALISER (#num_impr, #ref_detailsecteur)
SECTEUR (ref_secteur, libelle_secteur)
DETAILSECTEUR(ref_detail, libelle_detail, #ref_sect)
En fait ça revient à dire qu'une imprimante est rattachée à un détail secteur qui appartient à un secteur. Alors que normalement elle est rattachée à un secteur.
Bonjour,
avec une seule table, c'est gérable aussi, il suffit d'ajouter un champ "type" dans lequel on mettra IMPRIMANTE, LOCALISER, SECTEUR ou DETAILSECTEUR
Ensuite, il suffit d'ajouter les champs déjà mis plus haut : num, ref_modele, ref_secteur, libelle_secteur, ref_detail et libelle_detail. Et à chaque enregistrement, remplir tous les champs nécessaires via le formulaire.
Le listage se fera grace au champ "type". :)
avec une seule table, c'est gérable aussi, il suffit d'ajouter un champ "type" dans lequel on mettra IMPRIMANTE, LOCALISER, SECTEUR ou DETAILSECTEUR
Ensuite, il suffit d'ajouter les champs déjà mis plus haut : num, ref_modele, ref_secteur, libelle_secteur, ref_detail et libelle_detail. Et à chaque enregistrement, remplir tous les champs nécessaires via le formulaire.
Le listage se fera grace au champ "type". :)
Ca ne me parait pas très normalisé...
Qu'est-ce que tu appelles "doublons" ? Le fait d'avoir par exemple souvent IMPRIMANTE comme valeur du champ "type" ?
Sandrine >> Entre lister (par exemple) tous les éléments de la table IMPRIMANTE ou lister tous les éléments d'une même table dont le type est IMPRIMANTE, je ne vois pas vraiment la différence, on se casse juste moins la tête avec les "croisements de tables", en utilisant ma méthode. ^^
(Je l'utilise pour l'un de mes projets et c'est très efficace)
Sandrine >> Entre lister (par exemple) tous les éléments de la table IMPRIMANTE ou lister tous les éléments d'une même table dont le type est IMPRIMANTE, je ne vois pas vraiment la différence, on se casse juste moins la tête avec les "croisements de tables", en utilisant ma méthode. ^^
(Je l'utilise pour l'un de mes projets et c'est très efficace)
En gros, il n'y a plus qu'une seule table dans laquelle tous les enregistrements sont faits.
Par exemple, la table "general" regroupe les données des 4 tables précédentes :
IMPRIMANTE, LOCALISER, SECTEUR et DETAILSECTEUR
On met les champs principaux (ceux qu'il faut vraiment renseigner) au lieu d'indiquer dans chaque table la référence correspondant à l'enregistrement dans les autres.
Par exemple, la table "general" regroupe les données des 4 tables précédentes :
IMPRIMANTE, LOCALISER, SECTEUR et DETAILSECTEUR
On met les champs principaux (ceux qu'il faut vraiment renseigner) au lieu d'indiquer dans chaque table la référence correspondant à l'enregistrement dans les autres.
Ah ben si y'aura bien un problème de doublons dans le sens qu'on aura
ImprimanteX secteurA détailsectA1
ImprimanteX secteurA détailsectA2
ImprimanteX secteurC détailsectC1
etc...
puisqu'une imprimante peut avoir plusieurs secteurs et plusieurs détails secteur. On a donc une prise de mémoire trop importante.
ImprimanteX secteurA détailsectA1
ImprimanteX secteurA détailsectA2
ImprimanteX secteurC détailsectC1
etc...
puisqu'une imprimante peut avoir plusieurs secteurs et plusieurs détails secteur. On a donc une prise de mémoire trop importante.
On peut toujours mettre une condition s'il existe plusieurs cas de "ImprimanteX et secteurA" en comptant le nombre d'enregistrements, afin de les regrouper.
Par exemple une seconde requête va regarder s'il en existe plusieurs et si oui les listera.
Par exemple une seconde requête va regarder s'il en existe plusieurs et si oui les listera.
"si peu" : donc incompatible avec une augmentation conséquente du volume de données, ce qui impliquerait une refonte de toute l'organisation de la base. Et ça, ce n'est pas envisageable, quand on a les moyens de faire en sorte que la structure soit évolutive.
C'est un peu comme si tu avais à gérer des employés de différentes entreprises. La logique de l'analyse voudrait qu'il y ait une table "employes" en relation avec une table "entreprises". Il est certes possible de ne faire qu'une table "employes" avec comme champs les détails de l'entreprise. Ce n'est pas normalisé (même pas 1FN je crois), mais ça marche. Sauf que le jour où les données montent en flèche et atteignent plusieurs milliers d'employés dans ta table... déjà, elle sera énorme du fait d'avoir employés et entreprises dans la même... mais surtout, le jour où une entreprise change de dénomination : tu te vois mettre à jour plusieurs milliers de lignes dans ta table ?
C'est un peu comme si tu avais à gérer des employés de différentes entreprises. La logique de l'analyse voudrait qu'il y ait une table "employes" en relation avec une table "entreprises". Il est certes possible de ne faire qu'une table "employes" avec comme champs les détails de l'entreprise. Ce n'est pas normalisé (même pas 1FN je crois), mais ça marche. Sauf que le jour où les données montent en flèche et atteignent plusieurs milliers d'employés dans ta table... déjà, elle sera énorme du fait d'avoir employés et entreprises dans la même... mais surtout, le jour où une entreprise change de dénomination : tu te vois mettre à jour plusieurs milliers de lignes dans ta table ?