[Résolu] - clé primaire obligatoire [SQL]

compte supprimé · Le 17/12/2007, à 12:02

Une clé primaire n'est pas obligatoire, surtout si tu n'utilises qu'une seule table. En revanche, si tu veux faire par exemple une seconde table par exemple avec les coordonnées des membres, tu auras des requêtes du genre :

select nom, note from coords left join ta_table on ta_table.num_membre = coords.num_membre where num_reponse = X

qui va te renvoyer le nom du membre et la note, par l'intermédiaire de la jointure des 2 tables par le biais du champ num_membre qui sera obligatoirement une clé primaire de la table coords...

A+

Dernière modification par faustus (Le 17/12/2007, à 12:02)

Martopioche · Le 17/12/2007, à 15:21

DJiK a écrit :

Vous êtes gentil les gars, mais avec tout ça, j'ai pas la réponse que j'étais venu chercher!
J'ai une table qui contient:
num_reponse
num_membre
note

num_reponse et num_membre sont des clés primaires dans d'autres tables, MAIS num_membre peut être vide (là j'avais mis les 2 en clés, mais ça va pas). Donc est-ce que je dois rajouter une clé primaire?
La seule requête jamais faite est "SELECT note FROM notes WHERE num_reponse = X" donc je n'ai jamais besoin de sélectionner par clé primaire.

Je vais essayer dé répondre directement à la question plutôt que de partir dans de grandes théories (qui sont justifiées, mais mettons nous à niveau )

Tu a une table :
table1(num_reponse, num_membre, note)

qui référence
table2(num_reponse, autreChose)
table3(num_membre, autreChose)

si table2.num_reponse et table3.num_membre sont des clef primaire, alors elles ne sont ni nulles, et leur contenu est unique. Dans ce cas, table1.num_reponse et table1.num_membre peuvent être déclarées comme clef étrangères.

Si table1.num_reponse ou table1.num_membre ne peuvent être obligatoires, alors elles peuvent bien entendu référencer une clef primaire, mais il est malvenu de les déclarer comme clef étrangère bien qu'il me semble qu'on puisse déclarer une clef étrangère nulle. Cependant, c'est considéré comme une mauvaise pratique. Déclarer Une clef étrangère a surtout comme fonction de grantir que la référence existe. Il s'agit alors de réellement savoir ce que sont tes contraintes d'intégrité.

Voila.

DJiK · Le 17/12/2007, à 15:51

Martopioche a écrit :

Dans ce cas, table1.num_reponse et table1.num_membre peuvent être déclarées comme clef étrangères.

num_reponse oui, mais num_membre peut être nul.

En bref, la réponse à ma question est non, je ne DOIS pas ajouter de clé primaire qui ne servirait qu'à être une clé primaire.

Et petite mise au point: je suis développeur web dans une petite boite, je dois connaitre HTML, CSS, Javascript, PHP, SQL, donner des coups de main au graphiste en ActionScript de Flash, gérer les serveurs web, courrier, FTP, un peu de relation client, facturation...
Alors en effet, je ne suis pas un expert dans tous ces domaines, mais mon HTML est valide, j'ai rarement des bugs de prog, et surtout nos clients se foutent que leur BDD soit intègre ou pas du moment qu'ils sont livrés vite et que ça marche.

nowan · Le 17/12/2007, à 16:24

wé, mais bon, quand on se lance dans ce genre de trucs, il faut qd meme avoir de vagues notions de formes normales et consorts. Si tu veux mon avis, le design de tes tables n'est pas bon. il doit certainement y avoir une autre solution. pcq ce je que je vois, c'est que tu essaies de réaliser un relation many to many avec un partie nulle.. un peu zarb.

Donc, à mon avais, si tu ne vois pas l'intérêt d'une PK, c'est que ton design est pas bon.

pcq si je comprends bien, tu peux avoir des gens qui ne sont pas membres qui ont répondu et qui ont une note... sauf que ces non membres, tu ne peux pas les identifier...

plmegalo · Le 17/12/2007, à 16:57

DJiK a écrit :

[
Et petite mise au point: je suis développeur web dans une petite boite, je dois connaitre HTML, CSS, Javascript, PHP, SQL, donner des coups de main au graphiste en ActionScript de Flash, gérer les serveurs web, courrier, FTP, un peu de relation client, facturation...
Alors en effet, je ne suis pas un expert dans tous ces domaines, mais mon HTML est valide, j'ai rarement des bugs de prog, et surtout nos clients se foutent que leur BDD soit intègre ou pas du moment qu'ils sont livrés vite et que ça marche.

Je pensais avoir répondu et contrairement à ce qu'a écrit Martopioche, ne pas être resté seulement théorique.

Je voulais simplement attirer ton attention sur le fait avéré dans le développement d'application et pour faire un parallèle parlant, qu'il est plus difficile de refaire les fondations (les données et leur structure) d'une maison que sa plomberie (PHP HTML, etc...). Je suis assez au courant des impératifs clientèles (ça ne fait que 18 ans que je travaille en SSII ). La BDD peut se comparer au fondations de ton application et je ne saurai trop te conseiller, au delà de petits conseils rapides sur un forum, de faire en sorte que ta base ait une structure saine dés le départ.

Et pour ça, il faut prendre le temps de se documenter et de comprendre au moins les bases des bases comme un bon professionnel consciencieux que tu sembles être. (ce n'est pas de l'ironie, je sais quelle galère ça peut être de devoir tout faire dans une petite boà®te et loin de moi l'idée de critiquer)
D'autant que ça te fera gagner un temps précieux plus tard... et la confiance de ton client accessoirement !

Mes conseils n'allait pas au-delà de ça...

Pour en revenir au cas concret, tu n'as pas répondu à la question sur le numéro de réponse (c'est surréaliste ) : est-il unique ?
Si aucune des données de ta table des réponses par membre n'est unique, tu dois en effet créer un identifiant unique : si tu ne le fais pas, ta table risque d'être inexploitable. En effet, tu ne pourras pas facilement rechercher ou identifier une note précise, si toutes les données de ta table peuvent être vides et/ou multiples et si cette table prend un volume important, le résultat de tes requètes (sans parler des temps de réponses) risque de devenir de plus en plus aléatoire...

Ce que je te conseillerai c'est d'ajouter simplement et si c'est possible et pertinent, une notion de date/heure. Ceci te permettrait d'exploiter tes données dans de bonne condition.

Mais comme je te l'ai déjà écrit, tu es seul juge du plus adéquat en fonction des demandes de ton client.

DJiK · Le 17/12/2007, à 19:35

J'ai p-e pas été clair sur mon problème! Pour moi c'est OK, mais je vous explique mieux à titre d'info. C'est un peu comme un forum oà¹ les gens peuvent noter l'intérêt d'une réponse avec des petits boutons (un peu comme sur scoopeo.fr ou wikio.fr).

Table réponses
num_reponse (primaire)
num_membre
texte
etc...

Table membres
num_membre (primaire)
pseudo
etc...

Table notes
num_reponse
num_membre
note

Au début j'avais mis num_reponse et num_membre comme clé primaire car un membre ne peut pas voter 2 fois pour la même réponse.
Seulement le client veut que les visiteurs non-inscrits puissent voter aussi. Donc le champ notes.num_membre peut se retrouver non-renseigné.

Alors je pourrais y rajouter un champ auto_increment qui soit clé primaire, mais j'en vois pas l'intérêt parce que je n'ai jamais besoin de chercher une note en particulier.

Je prend juste toutes les notes d'une réponse: "SELECT note FROM notes WHERE num_reponse = X"
Ensuite je fais la somme des résultats pour faire la note de la réponse.

Du coup je vois pas vos réticences à ce qu'il n'y ai pas de clé primaire. Mais notez bien que c'est la 1ère fois de ma vie que je fais une table sans clé primaire, je pensais m^ qu'on avait pas le droit, d'oà¹ m'a recherche sur le Net qui m'a conduit ici.
Vous savez tout.

x@v · Le 17/12/2007, à 19:46

en faite moi je ne me sers pas de clé indexer.
Pour une petite table on insère un enregistrement dans la table1 et en même temps dans la table deux. Donc tu dois dans table2 créer un champs id_etc, ou tu mettra ton deuxième ajout en une seule requete ou deux.
ce qui te permettra d'éviter les jointures et de jouer sur l'id de ta table mère.
Et donc tu n'as pas plus rapide.
En définitive c'est le langage de programmation qui fait le travail, en java ou en php. Tu dois préparer tes tables en fonction de ce que tu veux faire.
De cette manière j'ai fait un cms, que je vais surement mettre open source.
Mais maintenant que je fais du j2ee (je l'apprend) je n'est plus la motivation de faire du séquenciel.

Dernière modification par x@v (Le 17/12/2007, à 20:48)

plmegalo · Le 17/12/2007, à 19:51

DJiK a écrit :

(un peu comme sur scoopeo.fr ou wikio.fr).

C'aura eu le mérite de nous faire parler

x@v · Le 17/12/2007, à 20:41

Et petite mise au point: je suis développeur web dans une petite boite, je dois connaitre HTML, CSS, Javascript, PHP, SQL, donner des coups de main au graphiste en ActionScript de Flash, gérer les serveurs web, courrier, FTP, un peu de relation client, facturation...
Alors en effet, je ne suis pas un expert dans tous ces domaines, mais mon HTML est valide, j'ai rarement des bugs de prog, et surtout nos clients se foutent que leur BDD soit intègre ou pas du moment qu'ils sont livrés vite et que ça marche. tongue

et dire que je ne trouve pas d'emploi parce que je ne sais pas faire de l'objet en php, enfin j'en suis pas sûr, je ne le s'aurrai jamais ?

DJiK · Le 17/12/2007, à 21:50

x@v a écrit :

et dire que je ne trouve pas d'emploi parce que je ne sais pas faire de l'objet en php

à‡a je sais, mais c'est une question qu'on ne m'a jamais posé en entretien.

DJiK · Le 17/12/2007, à 21:54

plmegalo a écrit :

DJiK a écrit :

(un peu comme sur scoopeo.fr ou wikio.fr).
C'aura eu le mérite de nous faire parler

C'était une remarque gentille ou méchante?
Notre client est très "web 2.0" ce qui nous fait plutà´t marrer, je connaissais pas vraiment ces sites avant ce projet.

compte supprimé · Le 17/12/2007, à 22:12

Salut,

Table réponses
num_reponse (primaire)
num_membre
texte
etc...

Table membres
num_membre (primaire)
pseudo
etc...

Table notes
num_reponse
num_membre
note

Cette structure est redondante, donc mauvaise !
En effet, le couple de données

num_reponse (primaire)
num_membre

est stocké 2 fois. Et une seule suffit !

A+

Dernière modification par faustus (Le 17/12/2007, à 22:13)

x@v · Le 17/12/2007, à 22:51

Table réponses
num_reponse (primaire)
num_membre(clé indexer "doit être égal à  num_membre pour pouvoir récupérer le membre associé aux réponses, mais ne doit surement pas être prévu pour être unique")
pseudo
texte
etc...

Table membres
num_membre (clé primaire)
etc,...

ensuite en php c'est très facile
$sql = "select * from reponse where num_membre='$membre'";
$tableReponse = mysql_num_row($requette);
$ma_var=mysql_fetch_assoc($sql);
if($ma_var == 1)
    $req=mysql_query("select * from membre where num_membre='$ma_var'");

ainsi tu as sélectionné tes deux tables. De tête je ne connais pas trop la syntaxe( je fais plus de php )
Mais bon l'implémentation est visible. Il faut surerement bouclé dans un while le mysql_fetch_assoc();
Le mieux c'est de faire une fonction qui te retourne la réponse avec en argument la variable.
Donc ont peux constater que c'est l'implémentation au niveau du contrà´leur qui fait le travail et pas la base (qui est comme il l'est dit plus haut correspond au fondation).
Peux-t-on caster une variable en php ?

Dernière modification par x@v (Le 17/12/2007, à 23:05)

compte supprimé · Le 17/12/2007, à 23:02

Eh !

Tu fais une seule requête sur des tables jointes ! C'est justement à ça que ça sert, les jointures, les clés primaires, etc.
De toutes façons, il faut d'abord savoir quelles données doivent être extraites de quelles tables, en fonction de quoi... Autrement dit, qu'est-ce qu'on doit voir imprimé sur un papier (ou sur une page html) ?
Une requête bien construite sur des tables bien conçues, peut être beaucoup plus rapide qu'une boucle en php...

A+

Dernière modification par faustus (Le 17/12/2007, à 23:08)

plmegalo · Le 17/12/2007, à 23:03

faustus a écrit :

En effet, le couple de données
num_reponse (primaire)
num_membre
est stocké 2 fois. Et une seule suffit !
A+

Bien vu, à force de parler pour rien dire ça m'a échappé

x@v · Le 17/12/2007, à 23:04

d'accord avec toi, on peux faire une jointure, mais cette méthode ma permis de faire des petite fonction bien pratique. Faudrai faire des bench pour voir...
Donc il faudrai qu'il fasse une jointure, mais la petite bdd te semble valable ?

Dernière modification par x@v (Le 17/12/2007, à 23:09)

compte supprimé · Le 17/12/2007, à 23:10

Y a pas photo !

Sauf sur des table de quelques dizaines d'enregistrement.
Je peux te donner une requête mal écrite à tous les coups : celle de la gestion des playlists d'amarok entre autres. Quelques milliers de morceaux et ça rame sévèrement !

A+

x@v · Le 17/12/2007, à 23:20

je suis sous gnome
Est ce que c'est écrit en java,ihm les appli pour Linux ?
Il se pourrai que je me lance un jour, mais je ne connais que les ihm et Swing pour le moment.

Dernière modification par x@v (Le 17/12/2007, à 23:26)

Martopioche · Le 17/12/2007, à 23:31

Bon alors réponse collective :

je dois connaitre HTML, CSS, Javascript, PHP, SQL, donner des coups de main au graphiste en ActionScript de Flash, gérer les serveurs web, courrier, FTP, un peu de relation client, facturation...

Mouaip... T'aurai pas pu juste dire "je suis dev web dans une petite boite" ? C'eu été plus simple...

Lol, sans plaisanter le problème, c'est que dans certaines grosses boites, il en va de même. J'ai plusieurs projets oà¹ les bases ont par exemple été concues par les développeurs qui avaient des connaissances relatives. En gros, le classique est l'utilisation d'Oracle, mais finalement pour ne rien faire de plus que ce que permet MySQL, PostgreSQL ou autre solution moins cher sans avoir besoin des ressources d'Oracle. Ce qui m'a fait dans ma carrière définir 2 types d'"intégristes" ou disons d'"extrémistes" :

- Les BDistes pour qui toute base de données doit répondre à la 3eme forme normale, avoir clefs primaire secondaires, procédures stockées... Limite à incorporer toute la logique métier dans la base.
- Les applicationistes pour qui les bases de données ne sont que des collections de tables et dont toutes les structures de contrà´le doivent être géré au niveau de l'applicatif.

Personnellement, j'estime qu'il y a un juste milieu. Celui-ci dépend de ce qu'on souhaite faire de cette base. De manière fondamentale, elle doit contrà´ler l'intégrité de ses données, ce qui passe par certaines structures de contrà´le, et une certaine organisation des données (non redondance par exemple).

Cette structure est redondante, donc mauvaise !
En effet, le couple de données
est stocké 2 fois. Et une seule suffit !

Jolie intervention, mais parlons donc de la signification de cette redondance : dans la table 1, nous avons l'association entre la réponse (identifiée par son numéro) et le membre qui l'a écrite. Dans la seconde (table 3 donc), nous avons une référence à une réponse associée à un votant qui ne peut être l'auteur de la réponse. Là je suis désolé, mais je ne vois pas mieux...

Donc quand je parlais d'intégrisme et de théorisation (oui bon, ça existe peut être pas comme mot), c'est pour souligner qu'une base, en plus que d'être une série de tables et de règles de conception, représente quelque chose derrière. L'association de certains champs est aussi dictée par la relation qui unit ce qui représente ces données.

Néanmoins, la table 3 ne sert plus à rien : un inscrit ne peut voter 2 fois (sa présence sur cette table le lui interdit), mais dans les données présentées, rien n'empêche un anonyme de voter plusieurs fois.

Voila voila, bonne nuit

P.S. (edit) ah oui, j'ai oublié : oui, bien concevoir une BDD est fondamental car une fois implanté et utilisée, c'est plus que compliqué de revenir dessus. Mais dans le monde Java, heureusement qu'il existe un framework comme Hibernate qui permet de modifier rapidement le mapping des objets si la base change. Dans certaines limites...

Dernière modification par Martopioche (Le 17/12/2007, à 23:34)

compte supprimé · Le 17/12/2007, à 23:35

Tu peux essayer avec rhythmbox... à‡a rame aussi ! Je pense que ça tient justement à des requêtes sommaires associées à du code d'exploitation des résultats, plutà´t que des requêtes élaborées et optimisées qui renverraient des résultats déjà partiellement traités...

SELECT dfact, CONCAT( IF( carnet1.titre_id, CONCAT( titre, ' ' ) , '' ) , CONCAT( IF( carnet1.prenom <> '', CONCAT( carnet1.prenom, ' ' ) , '' ) , carnet1.nom ) ) AS client, carnet1.adresse1, carnet1.adresse2, CONCAT( pays, ' - ', cp, ' ', localite ) AS ville, CONCAT( carnet2.prenom, ' ', carnet2.nom ) AS artiste, IFNULL( rem, '' ) AS rem, fac.id
FROM fac
LEFT JOIN cli ON fac.cli_id = cli.id
LEFT JOIN carnet AS carnet1 ON cli.carnet_id = carnet1.id
LEFT JOIN titres ON carnet1.titre_id = titres.id
LEFT JOIN cps ON carnet1.cp_id = cps.id
LEFT JOIN art ON fac.art_id = art.id
LEFT JOIN carnet AS carnet2 ON art.ref_id = carnet2.id
WHERE MONTH = '12' AND YEAR = '2007'

Cette requête me sort les factures (date, client, adresse, remarques) de décembre 2007, avec plusieurs centaines de clients, plusieurs centaines de factures..., en quelques centièmes de seconde ! La même chose avec des requêtes successives dans des boucles php, je suis sûr que ça prend quelques secondes...

Quant aux applis pour linux, j'ai bien l'impression que c'est écrit en beaucoup de choses (python, par exemple).

compte supprimé · Le 17/12/2007, à 23:44

@martopioche

dans la table 1, nous avons l'association entre la réponse (identifiée par son numéro) et le membre qui l'a écrite. Dans la seconde (table 3 donc), nous avons une référence à une réponse associée à un votant qui ne peut être l'auteur de la réponse

Ça ne coule pas de source que ce soit bien ça, à moins que num_membre concerne tantôt un membre, tantôt non !
En tous cas, je ne trouve pas ça très clair.

A+

DJiK · Le 18/12/2007, à 00:59

Martopioche a écrit :

dans la table 1, nous avons l'association entre la réponse (identifiée par son numéro) et le membre qui l'a écrite. Dans la seconde (table 3 donc), nous avons une référence à une réponse associée à un votant qui ne peut être l'auteur de la réponse. Là je suis désolé, mais je ne vois pas mieux...

Merci! En effet, l'association n'est pas du tout la même dans les 2 tables.

Néanmoins, la table 3 ne sert plus à rien : un inscrit ne peut voter 2 fois (sa présence sur cette table le lui interdit), mais dans les données présentées, rien n'empêche un anonyme de voter plusieurs fois.

Oui, c'est ça. Mais il faut bien stocker les votes de tout le monde quelque part...

faustus a écrit :

à moins que num_membre concerne tantà´t un membre, tantà´t non !

Oui c'est pour ça que j'ai viré le fait que num_membre et num_reponse soit clés primaires dans la table notes, num_membre pouvant être vide...
Encore une fois la seule requête concernant cette table est la somme des notes pour une réponse. Aucune jointure d'aucune sorte!

Vous me semblez chercher un tank pour écraser une mouche.

compte supprimé · Le 18/12/2007, à 11:58

Je ne crois pas qu'on cherche des tanks pour écraser des mouches...
Il y a seulement quelques règles de bonne utilisation des bases de données qui, si elle ne sont pas respectées, alourdissent considérablement le travail, le ralentissent d'autant et même empêchent (ou rendent difficiles) des modifications ultérieures (que le client ne manque jamais de demander...).
Bien entendu, on peut aussi faire brutal, et bidouiller au fur et à mesure...

A titre d'exemple de bonne conduite : http://dev.mysql.com/doc/refman/5.0/fr/twin.html

A+

Dernière modification par faustus (Le 18/12/2007, à 12:09)

x@v · Le 18/12/2007, à 17:57

Impressionnant ta jointure, je ne suis rien...

SELECT dfact, CONCAT( IF( carnet1.titre_id, CONCAT( titre, ' ' ) , '' ) , CONCAT( IF( carnet1.prenom <> '', CONCAT( carnet1.prenom, ' ' ) , '' ) , carnet1.nom ) ) AS client, carnet1.adresse1, carnet1.adresse2, CONCAT( pays, ' - ', cp, ' ', localite ) AS ville, CONCAT( carnet2.prenom, ' ', carnet2.nom ) AS artiste, IFNULL( rem, '' ) AS rem, fac.id
FROM fac
LEFT JOIN cli ON fac.cli_id = cli.id
LEFT JOIN carnet AS carnet1 ON cli.carnet_id = carnet1.id
LEFT JOIN titres ON carnet1.titre_id = titres.id
LEFT JOIN cps ON carnet1.cp_id = cps.id
LEFT JOIN art ON fac.art_id = art.id
LEFT JOIN carnet AS carnet2 ON art.ref_id = carnet2.id
WHERE MONTH = '12' AND YEAR = '2007'

plmegalo · Le 18/12/2007, à 18:15

x@v a écrit :

Impressionnant ta jointure, je ne suis rien...

SELECT dfact, CONCAT( IF( carnet1.titre_id, CONCAT( titre, ' ' ) , '' ) , CONCAT( IF( carnet1.prenom <> '', CONCAT( carnet1.prenom, ' ' ) , '' ) , carnet1.nom ) ) AS client, carnet1.adresse1, carnet1.adresse2, CONCAT( pays, ' - ', cp, ' ', localite ) AS ville, CONCAT( carnet2.prenom, ' ', carnet2.nom ) AS artiste, IFNULL( rem, '' ) AS rem, fac.id
FROM fac
LEFT JOIN cli ON fac.cli_id = cli.id
LEFT JOIN carnet AS carnet1 ON cli.carnet_id = carnet1.id
LEFT JOIN titres ON carnet1.titre_id = titres.id
LEFT JOIN cps ON carnet1.cp_id = cps.id
LEFT JOIN art ON fac.art_id = art.id
LEFT JOIN carnet AS carnet2 ON art.ref_id = carnet2.id
WHERE MONTH = '12' AND YEAR = '2007'

Heureusement que ce post est résolu, sinon, je sens que ça va tourner au concours de l'ordre SQL le plus balaise..

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 17/12/2007, à 12:02

Re : [Résolu] - clé primaire obligatoire [SQL]

#27 Le 17/12/2007, à 15:21

Re : [Résolu] - clé primaire obligatoire [SQL]

#28 Le 17/12/2007, à 15:51

Re : [Résolu] - clé primaire obligatoire [SQL]

#29 Le 17/12/2007, à 16:24

Re : [Résolu] - clé primaire obligatoire [SQL]

#30 Le 17/12/2007, à 16:57

Re : [Résolu] - clé primaire obligatoire [SQL]

#31 Le 17/12/2007, à 19:35

Re : [Résolu] - clé primaire obligatoire [SQL]

#32 Le 17/12/2007, à 19:46

Re : [Résolu] - clé primaire obligatoire [SQL]

#33 Le 17/12/2007, à 19:51

Re : [Résolu] - clé primaire obligatoire [SQL]

#34 Le 17/12/2007, à 20:41

Re : [Résolu] - clé primaire obligatoire [SQL]

#35 Le 17/12/2007, à 21:50

Re : [Résolu] - clé primaire obligatoire [SQL]

#36 Le 17/12/2007, à 21:54

Re : [Résolu] - clé primaire obligatoire [SQL]

#37 Le 17/12/2007, à 22:12

Re : [Résolu] - clé primaire obligatoire [SQL]

#38 Le 17/12/2007, à 22:51

Re : [Résolu] - clé primaire obligatoire [SQL]

#39 Le 17/12/2007, à 23:02

Re : [Résolu] - clé primaire obligatoire [SQL]

#40 Le 17/12/2007, à 23:03

Re : [Résolu] - clé primaire obligatoire [SQL]

#41 Le 17/12/2007, à 23:04

Re : [Résolu] - clé primaire obligatoire [SQL]

#42 Le 17/12/2007, à 23:10

Re : [Résolu] - clé primaire obligatoire [SQL]

#43 Le 17/12/2007, à 23:20

Re : [Résolu] - clé primaire obligatoire [SQL]

#44 Le 17/12/2007, à 23:31

Re : [Résolu] - clé primaire obligatoire [SQL]

#45 Le 17/12/2007, à 23:35

Re : [Résolu] - clé primaire obligatoire [SQL]

#46 Le 17/12/2007, à 23:44

Re : [Résolu] - clé primaire obligatoire [SQL]

#47 Le 18/12/2007, à 00:59

Re : [Résolu] - clé primaire obligatoire [SQL]

#48 Le 18/12/2007, à 11:58

Re : [Résolu] - clé primaire obligatoire [SQL]

#49 Le 18/12/2007, à 17:57

Re : [Résolu] - clé primaire obligatoire [SQL]

#50 Le 18/12/2007, à 18:15

Re : [Résolu] - clé primaire obligatoire [SQL]

Pied de page des forums