Accéder au contenu.
Menu Sympa

libreassociation - Re: [LibreAsso] Recherche volontaire pour tester un logiciel de gestion de fiches (et plus si affinités)

Objet : Liste de discussion pour le groupe logiciel libre et monde associatif (liste à inscription publique)

Archives de la liste

Re: [LibreAsso] Recherche volontaire pour tester un logiciel de gestion de fiches (et plus si affinités)


Chronologique Discussions 
  • From: Vincent Calame <vincent.calame AT exemole.fr>
  • To: libreassociation AT april.org
  • Subject: Re: [LibreAsso] Recherche volontaire pour tester un logiciel de gestion de fiches (et plus si affinités)
  • Date: Thu, 30 Apr 2020 19:20:56 +0200
  • Authentication-results: vip.april.org; dkim=pass (1024-bit key; unprotected) header.d=exemole.fr header.i= AT exemole.fr header.b="pwI2ousg"; dkim-atps=neutral
  • Dkim-filter: OpenDKIM Filter v2.10.3 mail2.rio20.net EA1BE764A46


Je pense que je n'ai pas bien vu ce que la notion de
fiche recouvre en fait. La description de la doc m'a fait penser à la
mécanographie (je n'imaginais quand même pas trouver du COBOL
derrière), puis j'ai pensé à Hypercard, mais en fait je crois que je
suis assez loin du concept, peut être trop influencé par les ORM que
je manipule.

En fait, la construction de mon modèle de données a été plutôt empirique. À l'époque (vers 2003), je suis parti du peu que je connaissais, c'est à dire des bases de données relationnelles. Devant les limites rencontrées à l'époque, je les ai abandonnées et j'ai fait du NoSql sans le savoir...

Cela étant, vu ce qu'est capable de faire PosgreSQL maintenant, le choix serait différent. Traduit dans une base PosgreSQL (ce qui est d'ailleurs tout à fait possible à faire), cela donnerait la structure suivante :

- chaque corpus serait une table avec une série de colonnes de type texte (pour les sections de texte) et de colonnes de type XML ou JSON pour les « petits champs » d'information technique. Chaque fiche serait alors un enregistrement de cette table

- chaque thésaurus serait une table

La question se pose de la meilleure représentation des relations. Dans BDF, les relations sont N-N, n'importe quel élément (fiche ou mot-clé) peut être relié à n'importe quel autre élément. Cela va même un peu plus loin (si c'est possible)  que le  N-N car il y a un mécanisme de qualification d'un lien par un mode : un élément peut être relié plusieurs fois à un autre élément avec des modes différents. Typiquement, le mode peut servir à distinguer les liens qui indiquent qu'une fiche est la traduction d'un autre des liens qui indiquent que les fiches sont voisines.

Toutes les relations pourraient être gérées par une table unique avec trois colonnes : l'identifiant unique du premier élément, l'identifiant unique du troisième élément et le mode.

Vincent






Archives gérées par MHonArc 2.6.19+.

Haut de le page