Bon, ben à ce que je vois, on est sur la même longueur d'onde ! Et je ne veux *pas* avoir de code spécifique au calcul dans l'appli,(...)
Mon Dieu, comme je suis d'accord avec toi !
De mon côté, j'ai tout fait entre d'un côté les tables, et de l'autre, des vues et des triggers. Pas question, à quelque moment que ce soit, d'avoir le moindre calcul innérent à la cohérence de la base ailleurs que dans la base elle-même.
Pour le côté php, j'ai conçu des fonctions qui, selon l'appel, me conçoivent les requêtes à passer à la base de données. Comme tu souhaite apprendre par toi même, ce qui est fort louable, je ne te les propose pas !
Par contre, j'ai pu constater que php se démerdait très bien avec les tableaux, et je dois bien avouer que j'en ai usé et abusé dans tous les sens. Surtout des tableaux multi-dimentionnnels avec indices non numériques. C'est fort pratique pour récupérer les champs de fomulaires, dans un tableau à 3 dimentions qui me donne le nom du formulaire d'où les informations proviennent, la ligne ou l'indice, qui me permet de numéroter les requêtes ainsi générées, ainsi que les noms des tables et des champs.
Pour les problèmes de sécurités, les informations correctes vis-à-vis de la base de données sont dans la session, alors que les valeurs des formulaires ne sont que les clefs qui me permettent d'accéder à ces valeurs. Je ne sais pas si je suis clair, mais passons.
Pour le coup du pointage par clef usb, c'est une bonne idée, mais pourquoi ne pas prévoir un interface web (tout du moins intranet) sur lequel les gens peuvent éventuellement corriger les horraires oubliés ou "mal pointés". Il faudra de toute façon un tel dispositif, car tu ne peux décider pour les gens si leur absence correspond à un congé, un stage, un arrêt maladie ou une journée de R.T.T.
Enfin, ce ne sont que quelques idées en vrac, comme ça !
Bon courage, quoi qu'il en soit !
[^] # Re: Je ne sais pas si c'est la bonne méthode, mais....
Posté par Gyro Gearllose . En réponse au message champs "durée" et postgres. Évalué à 2.
Et je ne veux *pas* avoir de code spécifique au calcul dans l'appli,(...)
Mon Dieu, comme je suis d'accord avec toi !
De mon côté, j'ai tout fait entre d'un côté les tables, et de l'autre, des vues et des triggers. Pas question, à quelque moment que ce soit, d'avoir le moindre calcul innérent à la cohérence de la base ailleurs que dans la base elle-même.
Pour le côté php, j'ai conçu des fonctions qui, selon l'appel, me conçoivent les requêtes à passer à la base de données. Comme tu souhaite apprendre par toi même, ce qui est fort louable, je ne te les propose pas !
Par contre, j'ai pu constater que php se démerdait très bien avec les tableaux, et je dois bien avouer que j'en ai usé et abusé dans tous les sens. Surtout des tableaux multi-dimentionnnels avec indices non numériques. C'est fort pratique pour récupérer les champs de fomulaires, dans un tableau à 3 dimentions qui me donne le nom du formulaire d'où les informations proviennent, la ligne ou l'indice, qui me permet de numéroter les requêtes ainsi générées, ainsi que les noms des tables et des champs.
Pour les problèmes de sécurités, les informations correctes vis-à-vis de la base de données sont dans la session, alors que les valeurs des formulaires ne sont que les clefs qui me permettent d'accéder à ces valeurs. Je ne sais pas si je suis clair, mais passons.
Pour le coup du pointage par clef usb, c'est une bonne idée, mais pourquoi ne pas prévoir un interface web (tout du moins intranet) sur lequel les gens peuvent éventuellement corriger les horraires oubliés ou "mal pointés". Il faudra de toute façon un tel dispositif, car tu ne peux décider pour les gens si leur absence correspond à un congé, un stage, un arrêt maladie ou une journée de R.T.T.
Enfin, ce ne sont que quelques idées en vrac, comme ça !
Bon courage, quoi qu'il en soit !