une table dossart avec deux champs : année || numéro

Comment feras-tu le lien entre le coureur et son numéro de dossart?

oups c'est vrai j'avaais oublié ça, bah ajoute un troisieme champ id_coureur sur lequel tu pourras faire la jointure

Ok merci! Je vais refaire un récapitulatif des changements ... j'ai même oubliè un tableau pour le club!

Ce sera pour jeudi soir (très tard!)

J'ai donc encore un peu de temps!

- une table avec les participants


- une table avec le dossart


- une table avec les clubs

Comment trouvez-vous les différentes tables? Pas trop lourde? Types des 'variables'? Je suis preneur pour tous vos conseils ! ! !

Par après, il serait quand même mieux, avec toutes ces différentes tables, de faire un interface qui facileterait l'encodage!

pas mal, j'aurais cependant ajouté un id_dossard dans la table dossard en clé primaire. D'autre part, j'ai personnellement une préférence pour le type VARCHAR au liu d type CHAR : ça prend moins de place. Très schématiquement, un CHAR(50) prendra 50 caractères même si le nom n'en comporte que 10, alors qu'un VARCHAR(50) prendra un maximum de 50 caractère, mais pour un nom de 10 caractère n'occupera en place que 10 caractères + 1

Merci, je m'occuperais de cela ce soir.

La nuit portant conseil, je me suis rendu compte qu'il avait plusieurs problèmes:

- comment la table dossarts prendra en compte chaque dosart de chaque année pour tous les coureurs? Je dois quand même ajouter une variable pour chaque année?

- Je ne suis pas certain d'avoir la date de naissance de chacun! Donc dans une table (dossarts par ex) je vais devoir ajouter la catégorie pour chaque année?

Est-ce que j'ai fait une bonne nuit ou dois-je rester sur mes idées post-nocturne?

Merci

Salut,

Il te reste le problème du club.
Exemple si j'étais dans un club en 2005 (Kain Bruyere) et en 2006 j'en change (pour aller au PDT ).
La table dossards ne devrait-elle pas plutot etre une table avec une clef primaire sur annee + dossard => grace a laquelle on récupèrerait l'id_coureur et l'id_club ? (plutot que l'id_club dans courses_part)

A+
Marianne

pas mal, j'aurais cependant ajouté un id_dossard dans la table dossard en clé primaire. D'autre part, j'ai personnellement une préférence pour le type VARCHAR au liu d type CHAR : ça prend moins de place. Très schématiquement, un CHAR(50) prendra 50 caractères même si le nom n'en comporte que 10, alors qu'un VARCHAR(50) prendra un maximum de 50 caractère, mais pour un nom de 10 caractère n'occupera en place que 10 caractères + 1

Oui et non. Un CHAR te permet de garder une table de longueur fixe, plus rapide, et qui t'évite de faire des OPTIMIZE TABLE si tu fais des update/delete sur les champs variables.

Maintenant tout dépend de la longueur des champs, de l'écart maximum, et de l'utilisation de la table. Dans le cas de cette table là, des VARCHAR sont en effet plus appropriés.
NB : Au passage pour le sexe, tu peux utiliser un ENUM, c'est plus clair selon moi.

Il te reste le problème du club.
Exemple si j'étais dans un club en 2005 (Kain Bruyere) et en 2006 j'en change (pour aller au PDT ).
La table dossards ne devrait-elle pas plutot etre une table avec une clef primaire sur annee + dossard => grace a laquelle on récupèrerait l'id_coureur et l'id_club ? (plutot que l'id_club dans courses_part)

Merci Yeliel (pour info, c'est mademoiselle qui m'avait déjà bien aidé pour mes tables!)
Je ne voudrais même pas immaginer qu'un tel changement soit possible

... mais dans le cas, il faudrait en tenir compte! Je refais certaines tables en tenant compte de vos remarques et je vous propose cette nouvelle mouture!

Merci

j'aurais cependant ajouté un id_dossard dans la table dossard en clé primaire.

Ok, je le fais mais c'est bêtement car je ne vois pas à quoi cela peut servir ... mais je te fais confiance!

Merci

NB impossible, j'ai déjà une clef primaire id_coureur en auto increment! Qu'est-ce que je dois faire?

A propos de la clé primaire dans une table :

Il faut réaliser une chose importante: ce champ n'est pas toujours obligatoire. Il faut également tenir compte du fait que c'est une donnée indépendante des informations qui sont stockées : la clé primaire sert de point de repère pour les manipulation, surtout quand on travaille sur plusieurs tables à la fois pour faire des liens entre les tables.

J'ai vu plusieurs fois certains poser des questions sur les clés primaires en entier auto-incrémentées et demander comment combler les trous quand on supprime une ligne: c'est une mauvaise question parce qu'on ne doit pas combler ces trous et éviter d'utiliser la clé primaire pour autre chose que ce pourquoi elle est créée : pouvoir repérer très précisément une ligne dans une table.

A tout seigneur ... !

- Voici la table des classements pour une année: id_classement est auto increment et primaire.


- Voici la table des clubs (c'est une liste de tous les clubs existants): id_club est auto increment et primaire.


- Voici une table pour avoir une liste de tous les coureurs existants: id_coureur est auto increment et primaire.


- Voici une table pour définir la catégorie du participant: id_categorie est auto increment et primaire. Cette table a déjà fait ses preuves mais le soucis est que je ne suis pas certain d'avoir la date de naissance de chacun et que les catègories ne changeraient pas plus tard. Je me demande si on devrait pas l'entrer dans la table changements (ci-dessous)!


- Voici une table que j'ai rebaptisé 'changements' [ex-dossard] mais dont je ne suis vraiment pas certain du résultat ... je ne comprend pas bien les explications de Yeliel!

De plus comment entrer le tenir compte du club, du dossard, ... par coureur chaque année! Il me faudrait un peu lumière!

A propos de la clé primaire dans une table : ...

Tu ne mettrais pas de clefs primaires à quel endroit?

NB: j'ai lu ton observation après avoir poster mon message précédent

Tu ne mettrais pas de clefs primaires à quel endroit?

Personnellement, j'en mets systématiquement: tu ne peux jamais savoir comment va évoluer ton application à l'avenir et rien ne peut t'indiquer que tu n'en auras jamais besoin. Donc tu mets un champ de type INT en auto-increment et tu te tracasses pas trop avec ça: ça ne prend pas une place significative et ça ne ralentira pas les traitements.

Je suis surpris par le type DATETIME pour la date de naissance dans la table courses_part : je parierai pas ma chamise que tous les participants connaissent leur heure de naissance : un type DATE suffirait à mon avis amplement

De même, comme l'a précisé Damien, dans la table soc_categorie, pour le sexe, il n'y a que deux valeurs possibles: donc un type ENUM ('h', 'f') suffirait largement aussi avec par exemple default 'h' ou à la rigueur NULL mais lors de l'insertion de données, il faudra valider ton formulaire en rendant cette donnée obligatoire.

Enfin, pour la table changements, j'avoue que le but poursuivi m'échappe un peu : quel est donc le ien avec les autres tables et à quoi sert-elle ?