Bonsoir,
Je veux réaliser une petite base me permetant d'enregistré les données
d'un formulaire visible sur ce site http://users.rockweb.org/f4bph/
j'ai déjà conçu une base pour se formulaire mais il y a des erreurs avec celle-ci, donc je veux repartir de zéro.
Que dois je faire ?

Salut,

1/ S'il n'y a que ce formulaire ET que ton application ne bougera plus .... fait qu'une seule table. (*)
2/ Si ce n'est pas le cas .... il nous faudra un peu plus d'info pour t'aider.

(*) : Oui je sais c'est pas de la "Bonne N'analyse Dans les Régles de l'Art" .... mais c'est de la vrai vie. Faisons simple si cela est suffisant.

T'es-tu demandé si les tables correspondant à ce formulaire dans ladite base devront avoir des interactions avec d'autres tables en rapport avec d'autres parties du site.

Ce que je veux dire, c'est qu'un site étant un ensemble en principe cohérent, la base de données devrait refléter cette cohérence. Or pour le moment, tu as l'air de vouloir traiter chaque problème un par un en créant des bouts de base au fur et à mesure... À terme, tu risques d'avoir quelques problèmes.

Après réfléxion, je ne pense pas relier cette base à une autre base (autre table),
Pouvez-vous m'enoncer les deux cas de figure

Pourquoi persister à faire les choses à l'envers ?

On commence par concevoir la base de données et seulement après, on fait les outils qui serviront à l'alimenter et à l'exploiter.

je ne persiste pas à faire les choses à l'envers j'essaye de crée une base selon mes besoins et sans exemple je ne peux pas expliquer ce que je veux faire.

Pour les cases à cocher : Peut on saisir plusieurs valeur pour BANDE et MODE ? Si oui les valeurs possible pour BANDE et MODE risquent elles de changer dans le futur ?

Pour les autres champs les questions à te poser :

Est ce que l'info est obligatoire ou non => NULL / NOT NULL
Le nombre de caractére max pour les commentaires, noms, prénom etc ... => VARCHAR(n)

Laisse : ID INT NOT NULL AUTO_INCREMENT
Cela ne mange pas de pain et te simplifira la tache pour tes/ton formulaire(s) si tu dois faire des mise à jour ou des suppression ou un jour mettre ta table en relation.

Je vais essayer d'expliquer ça differemment.

Pour concevoir une base de données, il faut garder à l'esprit un mot primordial : "données". Il faut commencer avant toute autre chose par répertorier toutes les données que tu vas devoir manipuler dans l'ensemble de ton application. J'utilise le terme de "application" à dessein, il peut s'agir aussi bien d'un site web que d'un progiciel de gestion intégré. Ce faisant, tu vas te retrouver avec une liste de mots qu'il va falloir trier et regrouper : tu auras lors du tri un certain ménage à faire, supprimer les doublons, effacer "le bruit", c'est à dire ce qui en fin de compte est sans intérêt, puis regrouper ce qui reste en entités distinctes. Ces entités auront chacune un nom qui est l'un des mots de cette liste, mais également des propriétés qui seront d'autres mots de cette même liste (pas les mêmes bien sur)

De là, tu vas devoir déterminer ce qui relie les différentes entités entre elles. Je prends un exemple brut.
Tu as par exemple une liste de mot suivante:
- abonné
- nom
- prenom
- adresse res principale
- ville res principale
- adresse res secondaire
- ville res secondaire
On va limiter à ça : On peut considérer "Abonne", "Adresse" comme des entités distinctes.
- Abonne aura comme propriétés "nom" et "prenom";
- Adresse aura comme propriétés "adresse", "ville" et on peut définir "type" qui pourra avoir en valeur "principale" ou "secondaire"

On commence à discerner la structure de la base, mais en fait il faut arriver à faire abstraction de la base et ne pas penser en terme de "tables" ni "champs" mais "entités" et "Propriétés"

Partant de là, tu dois établir les cardinalités entre les entités. Un abonné peut avoir 1 ou plusieurs adresses, mais une adresse ne correspond en principe qu'à zéro ou un seul abonné.

Je te laisse sur ce schéma basique de chez basique, commence à repenser à ton application de cette manière: tu es dans la partie la plus compliquée et la plus longue, mais quand tu auras correctement tout analysé puis conçu une base cohérente, le reste sera infiniment plus facile à utiliser.

Je te recommande aussi vivement des tutos sur developpez.com et en particulier un document PDF sur la création de bases

Petite question exist il un logiciel gratuit pour réaliser celà ?

J'en ai trouvé un cette semaine mais je n'ai même pas eu le temps de l'installer pour le tester, c'est DBDesigner et il y a même un plugin pour le mettre en français. À ma connaissance, il est gratuit.

Ceci dit, pour la partie "Dictionnaire de données", le mieux c'est papier/crayon/logique

Et si tu as les moyens, il y a PowerAMC (Power Designer en version anglaise) de Sybase.

Par contre je rencontre un problème je ne sais pas si je dois crée une table pour bande et une table pour mode.

voici un exemple pour pjl :

* concours
- nom (texte)
- date (voir exemple 1er post)
+ bande
160m, 80m, 40m, 30m, 20m, 17, 15m, 12m, 10m, 6m, 2m, 70cm.(choix multiples)
+ mode
phonie, télégraphie, mode_digitaux.(choix multiples)
- report (texte)
- lien (url)
- infos (texte)

je ne persiste pas à faire les choses à l'envers j'essaye de crée une base selon mes besoins et sans exemple je ne peux pas expliquer ce que je veux faire.

Désolé mais quand tu as des données, qu'est-ce qui est important, c'est la facon de les saisir ou la manière dont elles seront exploitées ?

Un exemple : la redoute.
Un article n'y est saisi qu'une et une seule fois mais il sera visible de x facons :
- sur internet,
- sur minitel,
- sur l'écran de l'hotesse du relais la redoute,
- sur l'écran du chef de produit,
- sur ton bon de livraison,
- sur ta facture.
Et à chaque fois il y aura des données complémentaires d'affichée.
Le chef de produit aura besoin de connaître ses ventes et ses stocks, toi tu n'auras besoin que de connaître le délai de livraison.
On en revient donc à ce que Cyrano disait : Dictionnaire de données avec papier/crayon/logique.

Le formulaire ne sera qu'une aide finale à la saisie sachant que tu peux toujours remplir ta BDD à partir d'un client de celle-ci.

merci pour tes remarques pjl.

Comment dois je stocké des informations de checkbox (choix multiples) ?

Comment dois je stocké des informations de checkbox (choix multiples) ?

repartir du début ne doit pas t'obliger à oublier ce qui a été dit avant...

exemple appliqué à ton projet :

si pour 1 concours, tu peux avoir 1 ou plusieurs modes (1 ou n modes)

=> 1 entité "concours"
=> 1 entité "mode"

=> 1 relation "concours_mode"

chaque ligne de concours_mode reliera 1 concours et 1 mode
(pour chaque checkbox cochée => 1 ligne dans concours_mode)

Pour les cases à cocher : Peut on choisir plusieurs valeur pour BANDE et MODE pour un même formulaire saisit ? Si oui les valeurs possible pour BANDE et MODE risquent elles de changer dans le futur ?

Repond à ceci on pourra te dire comment modéliser au plus simple