Discussion :

[pierrot10]

Bonjour a tous.

J'ai une base de donnée et une table pour une société.
Cette société doit gèrer des frais pas intervention.
Par exemple, frais de réservation, frais d'électiricité, frais d'annulation, frais de repas, frais de... etc.

Dans ma table je vais donc crée des champs, mais j'aimerais pas créer autant de champs que de frais, car si par la suite le cient veut ajouter des frai, je ne veux pas aller dans la base de donnée pour créer un nouveau champs.

Alors j'ai pensé, (es-ce la meilleurs solution?), de créer qu'un champs "frais" et dedans j'enregistre les frais que le client aura séletioné, via un checkbox d'un formulaire.

Donc ou je doute, c'est la manière (et toujours si c'est une bonne solution) comment enregistrer les information.

Par exemple, je pourrai enregistrer dans le champs

f_res, f_anu,f_rep,f_ele

puis quan je dois extraire ces info, j'utilise la virgule pour les distinguer.

Simplement , je ne suis pas convaincu que c'est la meilleur solution.

Que me cosneillerez-vous pour que je n'ai pas besoin d'utiliser autant de champs que de frais?

Mille mercis pour vos lumières

[spin0us]

Faire une table typeDeFrais avec 1 champ id en auto_increment et 1 champ label pour l'intitulé.
Tu peux ensuite stocker les ids des frais séparés par ce que tu veux (, ou | ou ...) et idem pour les valeurs attachées. Du coup si ton client veux ajouter un type de frais pas de souci tu le fais sur la table typeDeFrais.

Ton sélecte se contentera d'afficher le contenu de la table typeDeFrais. Et quand tu affiches tes interventions, tu commences par lister tous les typeDeFrais que tu stockes dans un array avec en clé l'id et quand tu parcours tes interventions tu explode les ids des frais et tu as la correspondances avec l'intitulé.

[RunCodePhp]

Salut

Dans ma table je vais donc crée des champs, mais j'aimerais pas créer autant de champs que de frais, car si par la suite le cient veut ajouter des frai, je ne veux pas aller dans la base de donnée pour créer un nouveau champs.

De quelles table s'agit il ?
En tout cas, il est clair que rajouter autant de champs que de frais n'est pas du tout la solution.
Je dirais même 1 seul champ n'est pas non plus la solution, en supposant que tu faisais allusion à la table "interventions" (ou autre dans ce genre).


Il faudrait au moins 2 tables à mon sens.
- Une table "typeDeFrais" (comme l'a proposer Spin0us), donc un ID de type, et son libelle. Il faudra alors tenter d'insérer tous les différents types de frais, et pourquoi pas créer un type "divers" au cas ou aucun correspondrait.

- Une table "frais", qui accepterait au moins 3 champ, l'ID du frais (frais_id), l'ID de l'intervention (interv_id),et l'ID du type (id_type_frais).
Eventuellement un champ "montant", une date, etc ...
Celle ci rassemblera donc tous les frais de toutes les interventions et selon leur type.


Ici, tu devrais avoir aucun mal à rechercher par exemple les frais d'une intervention en particulier, ou de certains (par rapport à un type, d'une date ou d'un montant par exemple).

[spin0us]

Un genre de diviser pour mieux régner c'est sur que c'est beaucoup moins compliquer à gérer.