Discussion :

[Freedolphin]

Bonjour à tous,

Tout d'abord, j'ai hésité à choisir cette rubrique, car ma question pourrait aussi se trouver dans la section "Développement", mais bon.
Voici mon projet : créer un planning de disponibilités de bénévoles, chaque jour de l'année, par tranches dans la journée (matin, après-midi, soir).
La table des bénévoles sera classique (id du bénévole, nom, téléphone etc.).
Je ne sais pas bien comment appréhender la chose et j'aimerais avoir quelques idées. Je ne demande pas du tout à ce qu'on me fasse le job ! Mais quelques pistes seraient les bienvenues.
Faut-il créer une table par jour, avec l'id des bénévoles sur chaque tranche ? Ou une table par mois ? Comment voyez-vous cela ?

Je partirais bien sur une table contenant tous les jours de l'années, avec pour chaque ligne le jour et les 3 tranches, lesquelles seraient remplies par les id bénévoles, séparés par une virgule, pour traiter ensuite les données avec un formulaire et des cases à cocher.

Merci d'avance pour vos idées !

[CinePhil]

Bonjour,

Voici mon projet : créer un planning de disponibilités de bénévoles, chaque jour de l'année, par tranches dans la journée (matin, après-midi, soir).

Je suppose qu'il s'agit de jours calendaires ? C'est à dire que si le bénévole Dupont est disponible le 2 janvier 2024 après-midi, il ne le sera peut-être pas le 2 janvier 2025. Comment pourrait-il d'ailleurs le savoir 1 an à l'avance ?

Donc oui, il va falloir gérer un calendrier.

1ère chose à faire : écrire les règles de gestion des données.

Par exemple :
R1 : Un bénévole peut-être disponible lors d'une période et une période peut voir la disponibilité de plusieurs bénévoles.

De cette règle de gestion, on déduit le morceau de MCD suivant :
Benevole -0,n----est_disponible----0,n- Periode

Et de ce morceau de MCD, on peut déduire les tables suivantes :
te_benevole_ben (ben_id, ben_nom, ben_prenom, ben_telephone...)
te_periode_per (per_id, per_date, per_creneau)
tj_ben_disponible_per_bdp (bdp_id_benevole, bdp_id_periode)

Lors de la création de la BDD, il sera utile de créer par procédure SQL le calendrier des périodes.

[Freedolphin]

C'est exactement ça, merci pour ces pistes.
J'ai effectivement opté (entre autres) pour une table Bénévoles et une table Disponibilités, avec 1 jour par entrée, chaque jour ayant les id des bénévoles dispos séparés par une virgule, facile à afficher ensuite.

[escartefigue]

J'ai effectivement opté (entre autres) pour une table Bénévoles et une table Disponibilités, avec 1 jour par entrée, chaque jour ayant les id des bénévoles dispos séparés par une virgule, facile à afficher ensuite.

Il ne faut JAMAIS stocker une liste de valeurs dans une même colonne d'une même ligne !
C'est un viol de première forme normale qui compromet l'intégrité de la base de données, rend les requêtes comples, les performances désastreuses, la fiabilité également... Bref tout ce qu'il ne faut pas faire.

Ce n'est pas pour rien que Cinephil propose une table de jointure, c'est bien pour avoir une ligne pour chaque combinaison de personne et de période.
C'est la SEULE modélisation correcte dans votre contexte.

Pour l'affichage, il suffira de concaténer les différentes valeurs lues en table, rien de plus simple par SQL, en fonction du SGBD, vous utiliserez STRING_AGG(), GROUP_CONCAT ou autre

[Freedolphin]

C'est marrant, mais plus on me dit de ne pas faire un truc, plus j'ai envie de le faire.
Sérieusement, merci pour ces conseils, mais la modélisation plus élaborée que vous proposez est trop complexe pour moi et cette petite appli est réservée à deux ou trois utilisateurs, sur un site privé.
D'autant que je ne vois pas bien où est le danger, ce n'est qu'un champ texte contenant des "12,34,27" ou "8,17,23,24"...

[escartefigue]

Par exemple, comment savoir qui est affecté à la période 2

Avec votre méthode, pour le savoir parcourir le contenu "12,34,27", trouver les délimiteurs (les virgules), tenir compte que le chiffre "2" n'est pas la même chose que le nombre 2 etc...
Ensuite, il est impossible de faire une jointure directement entre une sous partie d'une chaine de caractères et l'identifiant de la période sans opérer une fonction, ça signifie qu'aucun index ne sera éligible et que donc les perfs seront très dégradées.
Enfin et surtout, rien ne vous interdira de créer des périodes qui n'existent pas, de créer plusieurs fois la même période dans la liste pour une même personne, etc. Bref de stocker n'importe quoi

Ce sont les fondamentaux de la modélisation d'une base de données. La modélisation que Cinéphil et moi-même proposons est très simple et évite tous ces écueils.

Parcourez l'article sur les formes normales de Wikipédia (en particulier la 1ère d'entre elles puisque c'est de celle-là qu'il s'agit ici)