C'était ça :
Par contre pour le coup des trimestres, là c un peu plus chaud : les champs de dates utilisent un type Date fourni (je crois) par le langage SQL lui-même, et qui offre pleins de fonctions de comparaisons, calculs sur des dates, vérification de validité, assistance à la saisie (1/83=>01/1983), etc... bref c'est très pratique. En le séparant en plusieurs champs pour le rendre plus polyvalent, on n'a plus la même flexibilité, et c vraiment chiant à gérer pour le programmeur...
Voilà c'est mon point de vue... ça vaut ce que ça vaut...
Ouais mais on peut toujours se dire qu'un bon programmeur (...je cherche un peu, là, j'avoue) va te transformer les 2 valeurs "Trimestre 2" et "1994" en une seule valeur de type date "04/1994" en un coup de clé à molette.
Moi je trouve que c'est plus flexible pour l'utilisateur, mais dans le champ mois il faut bien sûr mettre une liste déroulante (on va pas le laisser faire n'importe quoi, quand même).
Et j'aurai une admiration sans bornes pour le programmeur qui gérera ça ! (hein, chef ?)
Euh... j'ai pas bien suivi là...
La conversion 2 trim 94 => 04/94 n'est pas une trouvaille, c'est ce qu'on fait tous et là n'est pas le problème.
Le problème c'est : il fait comment après, le "bon programmeur", pour savoir s'il faut afficher "04/94" ou "2è trim 94" ? Elle est un peu unilatérale ta conversion, non ?
Gaffo >> regarde les quelques fonctionnalités que j'ai citées dans mon autocitation, et dis-toi que tes champs texte, ils vont pas les reproduire tous seul ces fonctionnalités, faudra bien que qqun (le programmeur
) s'en charge. Maintenant, le programmeur, il peut aussi décider de laisser l'utilisateur se démerder sans ces fonctionnalités -> si ça te plaît d'être obligé de taper les dates en entier pour que l'ordi arrive à piger ce que tu lui dit, ou d'avoir la possibilité de saisir involontairement une date complètement erroné (34/13/2003, 7è trimestre 2003 et j'en passe), libre à toi. Moi perso, ça me gonflerais profondément.
Pas drole du tout :grrr: 
