Discussion :

[Dime313]

Bonjour,

J'ai une table 'utilisateurs' contenant toutes les informations nécessaires (nom prénom identifiant mot de passe etc...)

Je gère donc de manière dynamique la création/modification/suppressions de ceux-ci.

J'ai ensuite un calendrier PHP, affiché mois par mois, sur lequel apparaît chaque jours (1 -> 30/31) ainsi que chaque utilisateur soumit au planning.

Chaque utilisateur aura donc pour chaque jour du mois un horaire spécifié, ou, un repos etc...

La question est un peu bête, mais comment stocker tout ça dans MySQL ?

Personnellement j'avais pensé a ça, mais ça me semble pas très pratique:

Je crée une table 'planning' avec une colonne DATE de type DATE (2010-12-12 par exemple), ou chaque création de journée dans le planning crée un ligne supplémentaire.

Ensuite, je pensais, a chaque création d'un utilisateur dans ma table 'utilisateur' ajouter une colonne dans ma table 'planning'.

Donc pour chaque journée créer dans le planning, il y aura un colonne pour chaque personne soumise au planning.

C'est une possibilité, sauf que pour le moment il n'y a que 20 personnes environ soumissent à se planning, donc au pire, il y aura donc 20 colonnes dans ma table 'planning'.
Le souci est que ce planning peut être amené à être utilisé pour 150 personnes, ce qui ne me semble pas être un solution optimale...

Avez-vous une autre idée dans la manière de concevoir le planning ?
Ou est-ce la seule méthode?

Merci !

[rikemSen]

Je me souviens avoir fait ça un jour en cours. Enfin, à peu près.

Ca ressemblait à un truc du genre:

Table jours, table utilisateurs

Dans jours tu as l'id de l'utilisateur, la date du jour, un champs texte libre du style=> 9h/12h ou "congé".

Ensuite pas besoin de table mois. Tout se passe sur le champs "date" de la table jour.

Pour le mois de janvier tu fais une requête du style

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SELECT * FROM jour WHERE date BETWEEN '2010-12-31' AND '2011-02-01' ;

[defcon_suny]

Salut,

C'est peut-être pas la meilleure méthode mais voici ma façon de procéder.

Autre que la table utilisateur, il y a une table "evenements" qui comprend

un identifiant
un timestamp de départ
un timestamp de fin
un type d'évènement (congé, maladie, autre...)
et enfin une clé étrangère sur l'id de l'utilisateur

Qu'en pensez-vous??

[grunk]

Une table utilisateur => tu l'as déjà
Une table planning => champs : id - date/heure - type d'événement
Une table utilisateur/planning => champs : idUtilisateur - idPlanning

A partir de là pas besoin de rentrer des données pour chaque utilisateur chaque jour. Tu insères des données que lorsque effectivement il se passe quelque chose pour cet utilisateur.

Pour l'affichage de ton calendrier il ne te reste plus qu'a faire une requête avec jointure sur les 3 tables pour la période de temps voulue. Tu obtiendras un tableau de tous les évènements du mois pour chaque utilisateur.

Qu'en pensez-vous??

Je suis pas super fan des timestamp. un datetime est tout aussi efficace et pas soumis à l'éventuel bug de 2038

[defcon_suny]

Une table utilisateur/planning => champs : idUtilisateur - idPlanning

Pourquoi cette table? un évènement correspondra toujours à un et unique utilisateur

Je suis pas super fan des timestamp. un datetime est tout aussi efficace et pas soumis à l'éventuel bug de 2038

Moi non plus, mais la comparaison des dates et quand même plus aisée et rapide avec l'utilisation direct de timestamp. Quant au bug éventuel de 2038... ca me paraît un peu léger comme argument ;-)

[rikemSen]

Soit dit en passant, d'ici là, quasiment tous les systèmes seront sous 64bits donc le timestamp qui plante.... J'y crois pas.

[grunk]

Pourquoi cette table? un évènement correspondra toujours à un et unique utilisateur

Pour essayer de normaliser au maximum le schema de bdd , voir ici pour plus d'info , mais aussi parce que rien ne nous dis que demain on voudra pas attribuer l'événement X à 12 personnes.

Moi non plus, mais la comparaison des dates et quand même plus aisée et rapide avec l'utilisation direct de timestamp. Quant au bug éventuel de 2038... ca me paraît un peu léger comme argument ;-)

Un datetime n'est pas moins facile à traiter qu'un timestamp, toutes les fonctions de date et de comparaison s'y applique. Le timestamp est pour le moment compris entre 1970 - 2038 ce qui n'est pas le cas du datetime. Alors certes dans 5 ans on auras tous des serveur 64bit mais c'est juste dommage de parier sur un changement de technos pour assurer la pérénité d'une appli plutot que de s'appuyer sur quelque chose qui marche déjà maintenant et marchera demain (enfin jusqu'en 9999 ...).

[Dime313]

Merci pour vos réponses !

En parlant de temps, dans ma tables 'horaires' (dans laquelle je stock les types d'horaires possibles) une colonne heure_debut et une colonne heure_fin, les deux de type TIME (MySQL).

Cependant, lors de l'affichage, il est affiché HH:MM:SS, or l'affichage des secondes est inutile, et je ne trouve pas le moyen de l'afficher en HH:MM, sauf en changeant mes type en INT et en insérant des TIMESTAMP UNIX via PHP, mais par souci de lisibilité, je souhaiterai concernant mon type TIME si possible.

[grunk]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT DATE_FORMAT(heure_debut,"%H:%i") FROM matable

?

[Dime313]

$selection2 = 'SELECT DATE_FORMAT(heure_debut,"%H:%i") FROM planning WHERE id_utilisateur = '.$data[id].' AND date = '.$date;

Ca me retourne rien, à part si je mélange tout avec les ' et "

[Dime313]

Joyeu Noël à tous !

$selection2 = 'SELECT DATE_FORMAT(heure_debut,"%H:%i") FROM planning WHERE id_utilisateur = '.$data[id].' AND date = \''.$date.'\'';

ne me renvoi rien, alors que :

$selection2 = 'SELECT heure_debut FROM planning WHERE id_utilisateur = '.$data[id].' AND date = \''.$date.'\'';

Me renvoi bien la l'heure mais sous la forme HH:MM:SS

[Dime313]

Bon, ben finalement j'ai trouvé la réponse ! (un vrai monologue lol)

$selection2 = 'SELECT DATE_FORMAT(heure_debut,\'%H:%i\') AS heure_debut FROM planning WHERE id_utilisateur = '.$data[id].' AND date = \''.$date.'\'';

il manquait un -> AS heure_debut