(Courriels de diversion: <imprimerons@dessiller-faisables.com> <retirant@organiseront-divertiront.com> <indeniables@accuse-expliquions.com> <unique@empietera-polluer.com> <bateleurs@sectoriseras-bouillonnera.com> <fluorescentes@segmenterions-conforterez.com> <mandait@oublierait-chiffrerai.com> <supplanterons@detention-avilies.com> <embargos@reparus-larguant.com> <saupoudrerions@obvenir-calomnie.com> )
Le Wed, 6 Nov 2002 19:14:27 +0100 Arnaud Rolly <arnaud.rolly@wanadoo.fr> écrivait : > Le client est un programme en C++/C/Ada, avec une belle (subjectif!) > interface graphique (Qt/Motif/Gtk). Le client interagit avec la partie > serveur avec des chausettes (en réseau, pour les intimes). Pour le client (essentiellement des requêtes et des formulaires à remplir), je ne vois pas l'intérêt des langages cités. Le JAVA ou PHP me semblerait nettement plus indiqué. Même le COBOL serait plus pratique que l'ADA. Pour nos membres débutants (ceux qui sont encore sous Windows) qui ont plus que d'autre besoin de s'informer, rien ne semble prévu à part une installation dans la douleur de cygwyn+gcc+ada+gtk+++, bien qu'il soit envisagé de développer trois clients. > II - Schéma de la base (modèle logique) > > Avec mon formalisme, inventé pour l'occasion : Je préfèrerait une formalisme admis, sur lequel il est plus facile de discuter. > [XXX] => référence à un enregistreme de XXX > > type_document = ( nom_type ) > categorie_document = ( nom_categorie ) Je suppose que l'absence de clés est volontaire pour alléger la lecture, je ne fais donc aucune remarque sur ce point. A moins qu'il ne s'agisse d'une simple énumération, mais dans ce cas il n'est pas nécessaire de créer une table. Conceptuellement, catégorie et type sont des termes vagues et génériques. Après réflexion, je crois comprendre que par type tu entends le type du support et par catégorie le genre. > auteur_document = ( nom, prenom ) Une liste des oeuvres simplifierait les recherches. > document = ( titre, isbn, année, [auteur_document], [type_document], > nombre_exemplaires ) La catégorie compte aussi. Certains documents ont plusieurs auteurs. La table ne distingue pas le document de référence des exemplaires que nous possédons, mais pour une gestion simplifié ça devrait suffire. Un champ de commentaire serait le bienvenue (notes sur l'état, par exemple). > classement = ( [categorie], [document] ) Cette table n'apporte rien comme le montre l'absence de champs original. Si l'usage montre son intérêt (en terme de perf, par exemple), elle peut être construite dynamiquement. > membre = ( nom, prenom, droits_gestion, droit_gestion_membre, > peut_emprunter ) Je ne comprend pas la différence que tu établie entre droits_gestion et droit_gestion_membre. Le champ peut_emprunter me semble artificiel. C'est une information qui peut être calculée. Sa seule justification est l'absence d'une liste des emprunts du membre. > emprunt = ( [document], [membre], date_emprunt, date_retour ) Voila. Mais comme je le disais dans un mail précédent, la gestion d'un bibliothèque est l'exemple type de sujet bateau sur lequel ont planché tous les étudiants en informatique, qui a été développé et redéveloppé dans tous les langages du monde et je ne vois pas l'intérêt d'en faire une de plus alors qu'on dispose de liens vers une bonne douzaine de versions libres qu'il suffirait d'évaluer. A+ CPHIL (qui ne s'occupe plus de ça après, c'est promis) --------------------------------------------------------------------- To unsubscribe, e-mail: projets-unsubscribe@savage.iut-blagnac.frFor additional commands, e-mail: projets-help@savage.iut-blagnac.fr