De manière générale, oui, on créerait un champ par attributs de la voiture ou du cours dans la table "cours" ou "voiture".

Maintenant si le nombre de caractéristiques est très grand et très variables d'une voiture ou d'un cours à l'autre, on peut aussi envisager une solution plus souple. Par exemple avec deux tables:

[u]caractéristique[/u]
[b]id
nom
[/b]
exemple de valeur:
1| Airbag
2| Couleur
3| Couleur_Siege

[u]caractéristique_voiture[/u]
[b]idVoiture
idCaracteristique
valeur
[/b]
exemple de valeur:
1|1| Oui
1|2| Noire
1|3| Cuir

Ce qui en gros nous donne une voiture noire avec airbag et sièges cuirs.

En gros:
Définir une nouvelle caractéristique, jamais utilisée jusque là = une insertion dans la table caractéristique.
Affecter une nouvelle caractéristique à une voiture = insertion dans caractéristique_voiture.

Alors évidement, la table caractéristique_voiture risque de contenir beaucoup d'enregistrement (Nombre de voiture * nombre moyen de caractéristiques par voitures) mais ces données seront accessible directement en sql pour toute manipulation: recherche, modification, etc... et donc en terme d'optimisation et consommation de ressources, c'est beaucoup plus optimale.

Ya des régles ?
Je croyais que seul la règle numéro 2 du webmaster était valables ?

Arf je crois avoir enfreints la première règle alors.

On vas prendre l'exemple d'une voiture, j'en ai plein a créer et chacune d'elle peut avoir plusieurs propriétés, avec par exemple, l'airbag, la clim etc ...

Dans ma base de donnée j'ai la table voiture et la table voiture_option, je ne peux pas les lier, car le nombre de champ peut être trop nombreux, par exemple une centaine.

Donc ce que j'ai fais c'est de lister la table voiture_option dans la page, avec un tableau php j'indique la valeur de chaque, je reprends ce tableau et je l'insère dans un champ de la base (Options).

Ensuite pour la modif, je split la chaine avec les virgules et je fais un in_array avec les champs de la table et ensuite un checked=checked.

Pour les réinserer dans la base je supprime ce qu'il y à dans le champ actuellement et je rentre le nouveau tableau.

Donc vous auriez simplement recréer un champ pour chaque option ? même si le nombre d'options peut atteindre 100 ou 200 (la c'était un exemple pour la voiture, mais ça pourrait être pour beaucoup d'autres cas).

Ok ok,
je vais essayer de mettre en place ta solution, si j'ai des soucis je reviens.
Merci

[quote="nouveau"]Je regarde depuis tout à l'heure je pense que pour chaque jour je vais créer un array d'horaire, le serialize pour le mettre dans une chaine de caractere dans ma bd et vis versa pour les ressortir.
Une bonne idée ?[/quote]

non. :wink:

Mettre un tableau serializé dans un champ, c'est contredire la première règle de la théorie de normalisation des bases de données[1]:

[b]1)tout les attributs contiennent une valeur atomique[/b]

La meilleure chose, et la plus simple a faire, est de faire un second tableau ou seront enregistrés les horaires, liés chacun par ID à un type de cours.

Parce que sinon, que se passera-t-il s'il faudra modifier un horaire ? en effacer un ? Appeler le tableau, le désérialiser, enlever l'entrée, en mettre un nouveau (dans quel ordre ?), resérialiser, renvoyer dans le tableau.. compliqué. Alors que si bien normalisé, une simple requête SQL suffira.

Et quid d'un aperçu global de la semaine ? Il faudra appeler [i]chaque[/i] cours (donc, plein de données complètement inutiles), sortir a chaque fois l'horaire, le désérialiser, retirer les informations nécessaires et traiter ? Alors qu'a nouveau une seule requête SQL suffirait..

Et si on veut que les stages du lundi ? Ou tous les stages entre 8 et 22 heures ? Et comment vérifier que deux cours ne sont pas enregistrés aux mêmes heures ?

Bref, faire comme tu le propose certes, c'est facile à imaginer et à implenter. Mais, avec un minimum de de prévoyance, c'est aller droit dans le mur..

(mais bon, c'est pas une application critique non plus, fais ce qui te semble bien, mais si tu dois retravailler ou si quelqu'un un jour doit replonger dans tes données.. ça risque de faire mal).


[1] [url]http://fr.wikipedia.org/wiki/Forme_normale_(bases_de_donn%C3%A9es_relationnelles)[/url]

Je regarde depuis tout à l'heure je pense que pour chaque jour je vais créer un array d'horaire, le serialize pour le mettre dans une chaine de caractere dans ma bd et vis versa pour les ressortir.
Une bonne idée ?

C'est pas toi qui donne la formation, dis ? :wink:

Sinon, dans une db bien normalisée, ça devrait pouvoir fonctionner.
Tu as une table ou tu as les types de stage, avec leurs données propres (matière, professeur, etc..)
Et dans une autre celle ou tu les lies à un horaire (avec un commentaire s'il faut). Ainsi, tu peux lier autant d'horaires que tu veux à un même type de stage.

J'ai oublier de préciser qu'il y a aussi les jours car un stage peut être le lundi, vendredi et dimanche avec des horaires différentes à chaque fois.
Pour les jour on a déjà mis des checkbox si "checked" alors enregistrement ...

Bonjour,
Je dois réaliser un formulaire permettant de saisir des données de centre culturel, la partie qui me pose problème est celle qui permet d'enregistrer un stage.
Dans celle si au niveau des horaires je veux pouvoir rentrer plusieurs horaires différentes avec une précision : par exemple "Le stage de programmation php , de 8h a 9h débutant , de 10h à 12h confirmé " et donc on va dire avec 4 horaire différentes maximum.
Comment réaliseriez vous ça ... au niveau de la base mysql surtout ainsi que des variable horaire...
Merci pour toutes vos idées future.