ok, alors moteur de recherches...
et il est vrai que tu as raison, bon nombre de chien sont déjà mort...

[quote="juliette"]
je ne vais pas faire un select de 100 000 chiens quand même ?

ou alors, est ce que dans ce cas la table concours devrait être rempli en même temps que l'enregistrement du chien

ou alors est ce que je dois faire un moteur de recherche juste avant le formulaire pour trouver l'id ?

ou alors sur cette table concours si je met le lof en FK au lieu de id_chien, on le connais toujours le lof ?

en fait je cherche a trouver facilement l'id d'un chien quand j'utilise un formulaire sur une autre table...[/quote]
Je crois bien que tu as répondu toi-même à la question : un petit moteur de recherche à partir du lof.

Mais sinon, la solution simple que je verrais, ce serait de partir de la fiche du chien avec dans cette fiche, un lien vers la page d'inscription au concours, lien comportant en paramètre son identifiant, quelque chose du style [i]href=""./incriptionconcours?idc=1234[/i] où « 1234 » est la valeur de clé primaire de l'individu. Mais attention à un détail : n'affiche ce lien qui que si tu es identifié comme admin du site ou propriétaire du chien, sinon, pas de lien, pour éviter des plaisanteries de bien mauvais goût.

Autre point : même en admettant qu'un jour tu aies 10 000 chiens inscrits dans la base, ça aura quand même pris un temps assez considérable pour monter une telle base, or entre-temps, certains chiens auront disparu de leur belle mort. Pour autant que je sache, la participation à un concours à titre posthume n'existe pas, ni chez les chiens ni chez quelque individu que ce soit de quelque espèce que ce soit, humains compris... Ça m'amène à penser qu'il manquerait peut-être une date de décès outre la date de naissance qui est déjà là de mémoire.

Resterait les inscriptions par groupes, par exemple tous les individus d'un club donné, mais je ne sais pas si tu aurais ce genre de possibilité à envisager. L'autre option à envisager également : la page membre ou le membre propriétaire inscrit lui-même son chien au concours : là, on simplifie considérablement la recherche puisqu'on veille à ce qu'il n'accède qu'à ses propres données, et donc, comme on a son identifiant de membre en clé étrangère dans la table chien, on sait à quelles fiches il pourrait accéder pour avoir le droit d'effectuer certaines opération, comme justement par exemple l'inscription de son toutou à un concours.

Enfin voilà, ce sont les idées en vrac qui me viennent, il existe peut-être d'autres options envisageables...

je crois que tu aurais mieux fait d'avoir peur... :D
je rencontre un premier soucis de compréhension:

j'ai des tables lié aux autre, ça c'est ok et on ne va pas revenir dessus, par contre comme elle sont lié je ne peut pas enregistrer un chien dans une table si il n'est pas déjà dans la table chien c'est normale ...

mais dans ma table concours, la je ne peut pas mettre non plus si il n'existe pas, c'est encore ok...
mais si un jour il y a 100 000 chiens inscrit et que je veux inscrire un nouveau chien par le formulaire concours:
comment faire pour trouver son ID_chien ? j'en ai besoin dans la table concours pour les lié ensemble
je ne vais pas faire un select de 100 000 chiens quand même ?

ou alors, est ce que dans ce cas la table concours devrait être rempli en même temps que l'enregistrement du chien

ou alors est ce que je dois faire un moteur de recherche juste avant le formulaire pour trouver l'id ?

ou alors sur cette table concours si je met le lof en FK au lieu de id_chien, on le connais toujours le lof ?

en fait je cherche a trouver facilement l'id d'un chien quand j'utilise un formulaire sur une autre table...

[quote="juliette"]...a mon avis votre forum n'est pas débarrasser de moi pour autant...[/quote]
Même pas peur :langue:

un grand merci Cyrano mais a mon avis votre forum n'est pas débarrasser de moi pour autant...
a très bientôt je pense :D

Ben yapuka :D

en fait non, je comprend parfaitement l’intérêt et c'est de moins en moins abstrait, je pense qu'avec un peut de manipulation et d'utilisation des différentes tables tout va s'éclaircir...

l'étape maintenant est de compléter ma bdd avec tout les champs don j'ai besoin suivant ton modèle ?

Disons pour tenter de faire plus clair : tu as différentes données indépendantes. Les chiens en sont une, les questionnaires en sont une autre même s'il y a éventuellement un lien à établir entre les deux. Photos, c'est est une autre : c'est certain que le lien est assez évident entre chien et photo, mais le fait de séparer les deux vient de ce qu'un chien peut faire l'objet de 0 à n photos alors qu'une photo concerne un chien et un seul. Si on mettait une ligne photo dans la table chien, tu ne pourrais en mettre qu'une seule, ou alors il faudrait que tu fasse le même genre de chose que tu avais au départ avec les votes : des chaines sérialisées pour enregistrer plusieurs photos sur la même ligne dans une seule colonne. Note bien que ça peut fonctionner aussi mais les limites risquent d'apparaître et tu serais obligée de mettre une taille de colonne importante pour garder de la marge. avec une table indépendante, ça ne dépend plus du nombre de photos mais des capacités de stockage de la machine où se trouve la base de données, tu avoueras que ça fait une sacrée marge ;)

Le principe général de la modélisation de base de données, c'est qu'on part en général d'un cahier des charges, ou ce qui en tient lieu, sorte de document plus ou moins complet qui décrit l'application et ses fonctionnalités. de ce document, on isole les mots-clés, ce sont les données qu'on va devoir manipuler. On les répartis ensuite de façons à identifier d'une part des entités et d'autre part des propriété de telle ou telle entité selon le lien qui peut être établi entre deux mots :
[list][*]0:0 : L'élément 1 n'a aucun lien direct avec l'élément 2;
[*]0:1 : L'élément 1 est lié 0 ou une seule fois à l'élément 2 : l'élément 2 est probablement une propriété de l'élément 1;
[*]1:1 : L'élément 1 est lié une et une seule fois à l'élément 2 : l'élément 2 est une propriété de l'élément 1;
[*]0:n : l'élément 1 est lié 0 à n fois à l'élément 2 : l'élément 1 est probablement une entité indépendante de l'élément 2 ou une propriété d'une autre entité;
[*]1:n : l'élément 1 est lie au moins 1 fois et au maximum n fois à l'élément 2 : même chose que le précédent mais il existe au moins une correspondance[/list]
On définit de la sorte les propriétés d'une entité. On rajoute ensuite un identifiant à chaque entité, ce sera la clé primaire de la table, et ensuite on met en place les clés étrangères ou, selon le cas, certaines tables relationnelles.

C'est comme la programmation : on part d'un problème global et on l'atomise en élément basiques beaucoup plus faciles à traiter individuellement.

Là, j'ai conscience que ce sont des concepts qui peuvent te paraître un peu abstrait, mais en les manipulant, ces concepts te sembleront de plus en plus évidents avec du temps et de la pratique.

ok, je comprend aussi qu'il y a des tables ou j'enregistre des infos sur les chiens ( a son sujet ) mais aussi des tables qui contienne des infos pour le chien de façon a alimenter son enregistrement...
donc on peut dire qu'il y a 2 sorte de table dans mon cas: les table qui contienne l'info a afficher sur le site et les tables qui contienne des valeurs pour mettre dans les premières et leurs rôle peuvent être inversé, tout dépend de la requête...

Ben n'hésite pas à poser les questions qui te viennent à l'esprit lorsqu'un point n'est pas clair.

Comme tu l'as effectivement compris, ce sera beaucoup plus efficace pour récupérer les données. Tu auras toujours à faire certaines jointures pour collecter des ensembles de données provenant de diverses tables, mais globalement, ce sera infiniment plus simple à gérer au niveau des ajouts de données : pas de calcul tordu à faire pour construire des chaines compliquées qu'il faudra décrypter ensuite pour pouvoir les exploiter dans tes pages.

Et en fait, tes pages ne changeront pas fondamentalement, ce qui devra changer, c'est la manière de manipuler les données, pour les collecter ou bien pour les insérer/modifier/supprimer. Dans la durée, ton système tiendra la route beaucoup plus longtemps et sera beaucoup plus facile à faire évoluer.

je comprend aussi que ce système permet aussi de gagner beaucoup de temps sur les rechercher dans la bdd puisque mysql n'aura besoin de ne comparer que de simple chiffes...

je comprend aussi que mon site presque fini avant de poster ici est a refaire entièrement...

si c'est ok , je crois commence a comprendre, malgré ça je te demande quand même ce qu'il me reste a faire sur le croquis, cette défragmentation dans me tête me perturbe un peut, jusque maintenant toutes mes infos étaient sur la même ligne et j’allais chercher les infos de la ligne requise, rien de plus. Aujourd'hui et comme tu me la fait comprendre ce système n'ira pas loin et donc je ne veux pas continuer comme ça mais honnêtement je n'ai pas encore tout compris...

Schématiquement, c'est exactement ça.

Disons, si on veut reformuler, que la clé primaire est une donnée système de la base de données qui identifie une ligne de façon unique. C'est pour ça que d'une part il faut éviter de s'en servir comme d'une donnée « [i]signifiante[/i] » qui elle pourrait être modifiée sans que ça affecte le reste des données. C'est également l'intérêt de l'AUTO_INCREMENT de MySQL qui permet de ne pas avoir à se soucier de sa valeur lors d'une insertion, MySQL gère ça très bien. D'autres SGBDs n'ont pas cette particularité même si en général on peut le contourner pour obtenir le même comportement.
La clé étrangère identifie une ligne qui fait référence à la ligne d'une autre table, donc comme tu l'as effectivement dit, on ne peut pas entrer une ligne en indiquant comme valeur de clé étrangère une référence inexistante dans la table référencée.

Les clés sont des index dans une base : partant de là, le SGBD ne les traite pas tout à fait simplement en les stockant comme les autres valeurs non indexées, il peut y avoir certains blocages pour maintenir la cohérence dans les données de l'ensemble des tables, ou encore d'autres opérations pour rendre le tout plus efficace.

alors après de longues de lecture, je comprend que PK correspond a la colonne principale d'une table et FK correspond a qui a une PK d'une autre table, FK doit vérifie l’existence de de l'id d'un PK pour ne pas enregistrer un chien qui ne serait pas inscrit dans la table et le colonne PK...
pas très clair tout ça:
PK = colonne importante d'une table
FK = se référer a la colonne importante d'une autre table (PK)
est ce que c'est ça ?

[quote="juliette"]en regardant comme ça, je ne comprend pas la différence entre le "id_chien " de résultat et le "id_chien" de photo un est FK l’autre pas ?[/quote]
Tu as raison, J,ai fait un oubli, id_chien dans Photo est bien une FK. Je vais corriger mon croquis.

Pose-toi la question suivante dans chacun des deux cas : Combien de fois un des cotés peut être lié à l'autre dans la relation et dans quel sens ?

Un chien peut avoir plusieurs photos sur sa fiche, mais une photo ne représente toujours qu'un seul et unique chien.
Le résultat concerne un seul et unique chien, mais un chien peut participer plusieurs fois successives et donc avoir plusieurs résultats.

Si tu saisis ce système de relation et pourquoi on met une clé étrangère d'un coté ou de l'autre, tu auras pratiquement abouti :)

en regardant comme ça, je ne comprend pas la différence entre le "id_chien " de résultat et le "id_chien" de photo un est FK l’autre pas ?