Bonjour,
Voilà j'ai du mal à trouver comment exécuter deux requetes SQL. Je suis sûr que pour quelqu'un d'expérimenté ce serait simple.
J'explique.
1) J'ai une table avec un champ 'libelle'. Je veux créer un autre champ qui reprenne pour chaque tuple exactement le contenu du champ 'libelle' déjà existant.

2) J'ai deux table qui ont un champ en commun. Je veux recopier le contenu d'un champ de la table 1 dans un nouveau champ de la table 2, pour le tuple correspondant.

Je me vois mal recopier le contenu de chaque champ, alors si quelqu'un a la solution, je lui dit merci d'avance.

Salut et bienvenue sur le hub

C'est quoi un tuple ?



Si tu as créé le champ dans MyAdmin, il te suffit de faire la requète :

en remplaçant évidemment nom_table et nouveau_champ par les noms que tu as donné...


Pour la 2 tu pourrais faire un petit script rapide

Ah merci à toi, je viens d'essayer ta premier solution ça a marché tt de suite.

Un tuple sauf erreur de ma part c'est une ligne de ta table.
Mettons t'as une table voiture avec 10 champs, chaque enregistrement c'est un tuple.

Ne me frappez pas si je me trompe.

Tu as une idée pour le "petit script"?
Il doit bien y avoir une requete sql qui permet ça je pense.

Merci déjà en tout cas pour la première réponse

Une fois ton nouveau champ créé et puis tu fais un Update.


Ca me semble assez évident jusque là.



J'imagine que tu as un identifiant commun dans les 2 table.
Donc tu ajoutes le champ dans la table2 et tu fais :



Si ça ne donne pas le résultat désiré, n'hésite pas à revenir. Et au passage, n'oublie pas de faire un backup avant



Un enregistrement.

T'es sauf pour cette fois, c'est correct !

Un tuple c'est , en mathématique, un élément d'un produit cartésien... générlameent, lorsqu'on parle d'une base de données, c'est simplement un ligne d'une table composée de plus d'un champ. En anglais c'est appelé un n-uplet ...

Pour en revenir au problème de Boumbadaboum,
1> je suppose que tu veux le "recopier" dans une autre table, car dans la même table cela n'a pas trop de sens...En fait je vais répondre à ta deuxième question également, c'est typiquement dans ce genre de cas qu'il faut créer une relation entre les tables. Sous mySQL pas de moyen de contraindre tes relations entre les table (pas de procédures stockées,...) , mais pour une requête SELECT tu as la clause JOIN .. par exemple :



Plus d'aide sur les JOIN : http://www.w3schools.com/sql/sql_join.asp

*EDIT* Pardon pour la redite ;D je rédigeais ma réponse et quelqu'un m'a devancé ;D

Ok merci j'essaye ça dès que j'ai fini mes crèpes. Je vous dit le résultat.


C'est quoi un backup?
Tu veux dire une sauvegarde au cas ou la table grille?
J'en ai déjà fait une demi douzaine avant et je les ai expédié un peu partout sur mes boites mail et d'autres pc lol

Parano? Qui a dit ça?

Bon je vous dis si ça a marché merci.

Je n'ai vonlontairement pas parlé d'UPDATE, recopier les champs est également une possibilité, mais pour être franc je ne te conseille pas ce procédé à moins que tes tables soient situées sur 2 bases de données distinctes et qu'elle doivent pouvoir être indépendantes.

Les relations servent (pas uniquement...il y a évidemment une notion d'abstration aussi, ...) à éviter les répétions de données qui sont généralement sources d'erreurs et de problèmes lors de changement manuel dans les champs. Bref à toi de juger de l'importance de l'homogénéité de tes données.

*EDIT* On est jamais assez parano dans le monde de l'informatique...

Bon alors voilà j'ai fini mes crèpes je reprend.

Je viens de tester cela pour la deuxième requête (première résolue donc):


UPDATE definitions, annuaire SET annuaire.categorie = definitions.categorie WHERE definitions.libelle = annuaire.libelleDef.

J'obtiens:
#1064 - You have an error in your SQL syntax near '
annuaire SET annuaire.categorie = definitions.categorie WHERE definitions.libel' at line 1

Le but est donc de copier le contenu du champ categorie de la table definition dans le champ categorie de la table annuaire.

ça vous dit quoi? (ok je m'attend à un truc du genre "ta requête vaut deux balles, t'as pas vu la grosse tache en plein milieu, vas dormir et tout... mais bon je persévère ! )

Merci d'avance

Bon après avoir répondu naïvement au début, je me suis mis à réfléchir... Moi je veux bien t'aider à faire ce que tu veux, mais est-ce vraiment une solution ? Je vois déjà pas l'intérêt de faire deux colonnes avec les mêmes informations, et je dirais "encore moins recopier les infos dans une autre table"... Pourquoi tu fais ça ? Comme l'a dit quelqu'un avant moi, au moment d'aller chercher tes infos tu peux les piocher dans plusieurs tables, pour que tu te retrouves à la fin avec les bons résultats, donc les recopier dans une autre table, est-ce vraiment la meilleure solution ?

Bien en fait le résultat souhaité est le suivant:

Quand une définition est sélectionnée (c'est pour un dico), des liens en rapport s'affichent.
Les définitions sont dans la table Definition, les liens dans la table Annuaire.
Je peux trier les définitions par catégorie.
Mais maintenant je veux trier aussi les liens de l'annuaire par catégorie pour une nouvelle rubrique du site (pas en ligne encore).
Comme les liens comportent un libelle commun avec la table definitions la catégorie de la définition "satellite" est la même que pour les liens "satellite" de la table annuaire.

Donc si je ne veux pas recopier pour chaque tuple de la table annuaire le contenu du champ catégorie du tuple correspondant de la table definitions, je dois trouver la bonne requête qui va le faire directement.
C'est tout.

Maintenant si vous avez une solution révolutionnaire à me proposer j'écoute hein.

Si tu as un lien entre les deux tables, ce que tu sembles dire, ça ne pose pas de problèmes... Tu peux donner la structure exacte de ta BDD, avec les colonnes en commun ?

C'est lors de la recherche des résultats que tu auras une requète sur plusieurs tables...

Bien en fait je ne vais pas détailler toute la structure des deux tables ça me semble fastidieux.
Voila pour les champs commun entre la table definitions et la table annuaire:

- definitions.libelle = annuaire.libelleDef (pas le même nom de champ mais même contenu, est-ce un prb?)
- definitions.categorie = annuaire.categorie.

avant l'id des liens étaient le même que l'id des définitions mais je vais trouver une autre relation avec un nouveau champ déjà créé.

Donc la question est bien de transvaser les catégories de la table definitions vers la table annuaire en sachant que le point commun entre chaque tuple est le contenu des champs libelle (table definitions) et libelleDef (table annuaire).

C'est mon premier site dynamique soyez indulgent svp

Bon sinon rq j'en ai pas pour trois heures:
Je fais un select de tous les libelles de la table definitions pour une categorie et j'insère ensuite la categorie pour tous les libelleDef ayant le même contenu dans la table annuaire.
Y'a que 8 catégories.
Mais bon il doit y avoir une requête pour faire ça d'un coup.

Le fait que tu n'ai pas le même nom de champs (colonne) ne pose pas de problème pour la relation, tant que tu déclare cette colonne comme clé étrangère, ou clé primaire selon le cas.

Maintenant décrire ta base de données est assez important dans la mesure ou la structure inluence la/les requêtes que nous alons te proposer...si tu veux faire rapide il y a ce programme pour la modélisation : http://www.fabforce.net/dbdesigner4/
C'est gratuit et pas très compliqué. Cela nous aidera beaucoup je pense...

*EDIT*
Je viens de relire un peu l'ensemble du post, en fait, ce que tu souhaite réaliser avec tes définition c'est réaliser une relation plusieurs à plusieurs ou n à n ... Tu devras donc passer par une table intermédiraire du type :
| idMot | idMotProche |
--------------------------
| 1 | 23 |
| 3 | 12 |
| 1 | 5 |

idMot et idMotProche sont en fait liés à la même table, on relie des tuples de la même table entre eux...

Maintenant cette table sera générée par ton application, les enregistrement peuvent être réciproques au moment de récupérer les mots proches : 1 -> 23 et 23 -> 1 par exemple...

Si tu travail exculsivement sur des mots proche orthographiquement tu peux utiliser des algorithmes de compraison de mots aulieu de faire la correspondance manuellement par cette table intermédiaire. C'est à voir, tout dépends du type de mot a "rapprocher"
PS: Sorry pour le long EDIT...

Bah non c'est sympa mais bon j'ai rien compris.

J'en reviens pas que ça soit si long pour une requête alors que pour la première des deux, ça a été réglé du premier coup. :o

En tout cas félicitations, ça marche webmaster-hub, on a des réponses :-)

- definitions.libelle = annuaire.libelleDef (pas le même nom de champ mais même contenu, est-ce un prb?)

En fait ce que tu pourras faire quand tu voudras afficher les sites... Je pense que tu auras dans ta page de la définition la variable $libelle qui correspondra à la définition ? Il te suffira juste de faire un


Il te faut quoi d'autre en fait ?

Bah je veux bien comprendre ce que sont les index et à quoi ils servent, quand les utiliser etc... parce que je suis en train de refaire la base au propre et je me posais la question justement

Je veux bien un chalet en bois, un jardin, quelques poules, un chien ou deux, un percheron, une petite piscine, des sapins aussi.

Sinon ça va, merci

Oui plus sérieusement:
J'utilise la requête ci-dessous pour remplir les champs catégories de ma table annuaire



Bon comme j'ai plusieurs champs libelleDef qui ont le même contenu je fais 5 ou 6 tuples à chaque fois.
Mais tout de même à chaque fois je dois copier coller la requete et changer le libelleDef du WHERE (c'est clair?)

Donc je voudrais en une seule grosse requete mettre à jour toute la table
du genre:
UPDATE `annuaire` SET `categorie` = 'sociale' WHERE `libelleDef` = 'ambiance' OR 'libelleDef'='mars' OR 'libelleDef'='navette' etc....

Bon, mais c'est quoi la bonne requête?

Donc la c'est plus une question c'est un cours sur les systèmes de bases de données relationnelles que tu veux... ça doit se trouver ;D

http://www.commentcamarche.net/

Sous la rubrique Bases de données tu les conceptes fondamentaux dont tu as besoin sous "Initiation" et "Modèle relationnel"...

PS+EDIT : Je continue à dire que une représentation graphique de ta base nous serait utile...

Dan

Je suis vexé

non je rigole, merci pour tout et je vais approfondir la théorie.

et merci Dan pour finir

Bah..pas de quoi se vexer

Dan à la rescousse, comme d'hab On le remerie jamais assez alors : MERCI !

Toutefois, Boumbadaboum, si tu dois effectuer de telles opérations c'est que il a un problème d'abstraction dans la structure de ta base de données, avoir des données redondantes dans une base n'est pas la solution la plus efficace...Mais c'est "tolérable" (ne soyons pas plus royaliste que le roi..) pour une application d'envergure raisonnable...

Bonne chance dans tes futures aventures de "base-de-donnée-esques" Et surtout bonne nuit ! (Non mais c'est pas des heures pour être debout ça...tantpis, je suis assis de toute façon... )

C'est quoi un "problème d'abstraction"?

Au moment ou tu as réflechi et modélisé ta base de données tu n'a pas décomposé le "problème" (le cas que tu souhaite traiter) sufisamment. Tu te retrouves avec des données redondantes (même données dans des tables différentes)... pour palier à ce problèmes il faut revoir la modélisation de ta base de données.

Mainteant comme j'ai di précédemment, pour un projet d'envergure raisonnable ce n'est pas un point critique. A toi de juger s'il est nécessaire de re-modéliser ta base de données

En fait plus qu'un insuffisance de modélisation des tables, certe probable, je dirais que c'est une insuffisance de connaissance du langage SQL qui me contraint à créer des tables un peu redondantes.
Par exemple comme je ne sais pas bien comment effectuer une requête comprenant une clef étrangère, et bien je "bidouille" une table avec des données redondantes.

Ca me permet d'avoir l'affichage souhaité coté client, mais ce n'est certe pas la solution idéal à moyen terme. Il faudra surement revoir les tables un de ces jours c'est sur. En fait je ne mesure pas bien les conséquences possibles d'une table mal construite (les données redondantes prennent de la place certe, mais à part cela? )

Effectivement c'est une autre possibilité. L'usage des clé étrangère est forcément incontournable créer de lien entre les tables.

Les conséquences sont comme tu l'a mentionné une perte de place (quoiqu'à l'heure actuelle on a tendance à ne plus trop s'en préocupper...), sur des grande quantitées de données un temps d'accès plus long (ça reste dans l'ordre des millisecondes je pense...) mais le plus important c'est la cohérence des données, à plus ou moins court terme tu risque d'avoir des différence entre tes tables...si je vulgarise, tes données ne seront plus "synchronisées", ces différence peuvent causer des problèmes..surtout lorsque tu en viens à les comprarer pour établir un lien entre deux tables, c'est une des principales raison pour lesquelles on ne relie pas (dans la théorie) en se basant sur une chaine de caractères...

Ceci est un bon exemple d'opération "à risque" si tes données ne sont plus "synchronisées"...



(J'ai repris ton exemple, mais ce n'est pas pour le critiquer, c'est ce qu'il faut faudrait si tu n'utilisait pas de clés étrangères !)

Ok merci
Une question pour me situer:
Vous avez quel niveau en informatique en général, vous autres qui répondez sur ce sujet par exemple.
Je veux dire: Pour s'y connaitre en sql au moins comme vous il faut un bac +2, + 4? 3 ans de pratique sur le tas?
personnellement j'ai un moins de pratique avec les BD et trois mois avec php

Presonnellement je suis pas Français... je suis un "petit" (1m94 quand meme) Suisse...

J'ai fait un apprentissage d'informaticien avec un bac technique, un début d'étude supérieurs pour devenir ingénieur en informatique orientation développement. Je dois avoir qqch come Bac+1 Mais bon je développe depuis très longtemps et j'ai toujours été très auto-didacte...avec les avantages et les inconvénients que cela implique

Les années de pratique on va dire.. euh j'ai 21ans...j'en ai passé 11 à développée au niveau professionnel et privé. J'en ai fait mon métier à plein temps en créant un entreprise cette année avec un associé...mais très de présentation, on est pas dans la partie "Nouveaux membres" ;D ...

Ok merci ça m'aide à situer le niveau

Félicitations pour ta boîte et bosses dur !