Gestion de vos collections

Bonjour tout le monde,

Je cherche à inventorier tout le fatra que j'ai (fusils et militaria) : utilisez vous une logiciel en particulier ? ou un bon vieux excel ?

Je regarde le logiciel Numento, mais on ne peut pas dire que ce soit vraiment dédié armes à feux…

Bonne journée ,

Max

Si l'on veut à toute force faire ça sur ordinateur, il faut utiliser un logiciel adéquat.

Excel c'est un tableur, particulièrement optimisé pour gérer des colonnes de chiffres avec interactions mathématiques entre les colonnes ou les lignes. Alors bien sûr certains utilisent le tableur pour gérer des textes, et même pour présenter des tableaux d'informations-texte ; ce qui donne un résultat allant du médiocre à l'immonde.

Pour gérer des informations de types divers (textes, chiffres, voire images), il y a les logiciels "base de données", qui offrent généralement la possibilité de définir une apparence par fiches bien plus évidente que des colonnes de cellules.
- Le plus connu était Access (Microsoft) mais c'est un gros camion et la licence était coûteuse.
- J'ai autrefois beaucoup utilisé le module "base de données" de l'ensemble ClarisWorks, moins cher et parfois inclus dans la pré-installation d'un ordinateur neuf. ClarisWorks était très commode pour dessiner des interfaces graphiques de fiches permettant une consultation agréable de la base, et on pouvait sauvegarder sous divers formats permettant de reprendre les données sur un autre logiciel ou même de les "lire dans le texte" en format TXT (ce que permet d'ailleurs aussi Excel).
- Plus tard, désirant certaines fonctions absentes de ClarisWorks, je n'ai pas perdu de temps à chercher un logiciel me convenant mieux et il m'a paru plus simple de l'écrire entièrement ; ça ne m'a pris que quelques mois et je m'en sers toujours en ajoutant de temps à autres quelques améliorations (ces temps-ci, pour classer la documentation réunie dans le cadre d'une étude menée avec quelques membres de TCAR).
- Les "suites logicielles gratuites" actuelles, comme OpenOffice ou LibreOffice, paraissent systématiquement contenir un module "base de données", mais je n'en ai essayé aucun et n'ai donc pas la moindre idée de leur agrément d'emploi.

La mode est aujourd'hui aux bases de données "relationnelles", ou résidant sur un ordinateur distant, ce qui n'est pas d'un grand intérêt dans le cas présent ; un vieux logiciel démodé peut donc très bien faire l'affaire, si le système condescend à le faire tourner. Le plus important est ici la facilité à dessiner une interface graphique agréable pour les fiches (et imprimable, éventuellement) ; la gestion de courts textes ne doit pas poser de problèmes, mais le paramétrage de recherches sélectives (afin de sortir une liste des fiches répondant aux critères spécifiés) pourrait être moins satisfaisant, ou rébarbatif.


PS : ne sachant pas de quoi l'avenir sera fait, ni dans quelles conditions on pourrait vouloir consulter son fichier, il n'est pas inutile de choisir un logiciel proposé pour divers systèmes d'exploitation ; ou même un logiciel "multi-plateformes", fonctionnant directement sur les principaux systèmes.
C'était une des raisons pour lesquelles j'en avais écrit un moi-même, en langage Java, dont le code et le fichier de données fonctionnent indifférement (et à l'identique) sous Macintosh 9 et X, Windows 95 à 10 (pas testé sous Windows 2000 et Vista), et 1 ou 2 Linux (j'ai pas eu l'occasion d'en essayer beaucoup).

Tout à fait d'accord avec l'inadéquation d'un tableur, quel qu'il soit, avec la tâche : ça peut dépanner mais c'est au mieux du bricolage.

Adepte convaincu depuis des années du génial PostgreSQL, je me suis monté ma petite base perso avec mais faute de temps pour, je n'ai toujours pas développé d'interface dédiée donc j'utilise un frontal "générique" (DBeaver) qui me suffit pour le moment. 

Sans trop entrer dans les détails, j'ai parmi différentes tables, en plus des armes elles-mêmes, les marques, les pays, les calibres, les poudres, les types de balles, les tirs effectués, les catégories, les photos... et sûrement quelques autres auxquelles je ne pense pas (flemme de lancer le truc pour vérifier, là).

Un gros avantage d'une base SQL, c'est qu'on peut tout exporter en un seul fichier et recréer à volonté "n'importe où"...

Exact, je valide que le fait d'utiliser un tableur n'est ni idéal, ni beau. Ni rien en fait.
J'ai bien fait un catalogue à la main, mais étant geek dans l'âme...
Bon et bien je vais regarder ce qui est faisable avec une petite base postgres. Quitte à développer un front pour avoir une belle interface.
Je suis en congé paternité et informaticien : je pense trouver un peu de temps entre 2 couches et les micro siestes 
Si je ne me penche pas plutôt sur la modélisation d'un canon de 155C 1917 Schneider en 3D avant ! Petit devoir de mémoire de mon arrière arrière grand père qui a fait Verdun sur ces gros lances marmites.
Max

Je me souviens qu’on trouvait un logiciel ad hoc, mais le temps passant, tout à coup il y a le risque que cela ne marche plus…

Au plus simple, un tableau Word…

J'utilise Libre Office et Microsoft Office. Les deux comportent une base de données Access pour Office et Base pour LO.

Base a une bonne réputation et LO est gratuit (quoique verser son obole me semble indispensable...)

Microsoft Office vaut environ 100 € en licence à vie.

Beavounet a écrit:... Quitte à développer un front pour avoir une belle interface. ...

Pour ce genre de catalogue, l'apparence graphique est de très loin le plus important car c'est ce qui détermine la lisibilité.

Le fâtras interne des bases de données, dont on fait un tout un fromage, n'a ici que très peu d'intérêt, voire même aucun (sauf à vouloir croiser plusieurs bases de données indépendantes, "Armes", "Tables de rechargement", "Résultats de tir"... Par contre, les petits gadgets qui peuvent être utiles, une base de données "à la dernière mode" ne les proposera pas forcément.

Exemple : sur la fiche dédiée à une arme, vous avez prévu un champ pour lister les documents afférents, qui peuvent être des manuels d'utilisation en PDF, des témoignages d'époque en DOC, des photos, etc. Il serait utile qu'en double-cliquant la ligne de cette liste, ledit document s'ouvre automatiquement dans son logiciel usuel.
Pour une image, on pourrait en plus demander qu'elle s'affiche en vignette de prévisualisation avant de lancer le logiciel l'ouvrant "plein format".
C'est le genre de choses qu'il y a 25 ans je n'avais pas trouvé, et c'est une des principales raisons pour lesquelles j'avais écrit mon logiciel de base de données ; sinon ClarisWorks aurait pu suffire.

Ian McCollum a participé à l'élaboration de cette base :



lien catalogit

je ne l'ai pas essayé, je ne sais pas ce que ça vaut.

Aardvark a écrit:Ian McCollum a participé à l'élaboration de cette base :



lien catalogit

je ne l'ai pas essayé, je ne sais pas ce que ça vaut.

Je viens de regarder le lien.
Merci de l'envoie, par contre on peut s'interroger sur la notion de propriété des données que nous insérons sur ce site.
Il semblerait que ce soit un site américain tournant à partir d'une proposition d'Amazon. Il faut donc accepter de ne pas être propriétaire des données que nous insérons sur ce site.

Rigoureusement AUCUN intérêt (au moins pour moi) :

• C'est du cloud-only
  
• Pas libre ni même "simplement open source"
  
• à partir de 50 entrées, c'est payant
  

Je VEUX avoir 100% de maîtrise sur le truc. Pas question que quoi que ce soit soit hébergé hors de chez moi.

Joel_ a écrit:Rigoureusement AUCUN intérêt (au moins pour moi) :

• C'est du cloud-only
  
• Pas libre ni même "simplement open source"
  
• à partir de 50 entrées, c'est payant
  

Je VEUX avoir 100% de maîtrise sur le truc. Pas question que quoi que ce soit soit hébergé hors de chez moi.

  quand on sait comment certains sites sont souvent attaqués et des données volées....

Pour illustrer mon propos je me suis fendu de 2 copies d'écran (tout l'écran, y compris la barre Windows).

D'abord le tableau tout simple, sur un quelconque logiciel de traitement de texte, format dit "Tab-Return" : une ligne par fiche (ou "enregistrement"), sur laquelle les informations (ou "champs") sont séparées par des tabulations.
Quand d'une fiche à l'autre les informations de même niveau sont de longueur très variable, c'est difficile à aligner. Quand le total des informations d'une fiche dépasse la longueur de ligne, c'est difficile à lire. Sinon c'est simple et rapide ; à noter qu'un tableau ainsi formaté peut s'importer aisément sur n'importe quel tableur ou base de données, donc pour un premier jet c'est intéressant.

Sur un tableur c'est structuré de même façon, mais les lignes et colonnes sont délimitées par une grille, et les informations trop longues s'enroulent dans la cellule (si elle est étroite c'est souvent presque illisible). L'objectif principal d'un tableur est de remplir automatiquement certaines cellules par le résultat de calculs mathématiques entre des cellules déterminées. On pourrait donc faire automatiquement calculer la longueur de l'arme multipliée par le calibre, puissance "le nombre de rayures", divisé par la "date-modèle" ... ce qui ne présente strictement aucun intérêt !



-----------------

Ensuite, les mêmes informations (catalogage de documents anciens) sur un petit logiciel de base de données. Ce qui est affiché est le résultat d'une recherche effectuée par le logiciel : les 5 fiches affectées du type "bibliographie", sur un total de 146 fiches (un choix que j'ai fait pour éviter de déflorer le sujet, il s'agit de documents que tout le monde connaît).
Je constate à cette occasion que les données biographiques de Challéat sont fausses, faut que je rectifie ça !



S'agissant du catalogage de documents, le formulaire d'affichage a été organisé en vertical (ici à gauche) afin de laisser une surface d'affichage permettant de visualiser les documents (ici à droite, un PDF sur AcrobatReader).
Tout à gauche, la liste des fiches (totale ou répondant à la recherche précédente) ; ensuite le contenu de la fiche sélectionnée (celle qui est en surbrillance dans la liste), structuré par champs, chacun défini par un nom. Si on clique une autre ligne de la liste, le contenu des champs change et reflète la fiche concernée. La disposition des champs, leur nom et le type de composant sont définis par l'utilisateur, selon ses conceptions de la commodité d'emploi (c'est pas simple, car l'écran est toujours trop petit).
Le type de composant présente une grande importance pour la commodité d'emploi. Certains permettent de saisir un texte libre sur une ou plusieurs lignes, mais d'autres "encadrent" mieux les données : par exemple choix de termes limités à une liste prédéfinie, date en refusant tout ce qui ne peut pas être traité comme une date, etc.
Le composant "DOCS" est plus complexe : il liste des fichiers informatiques, et en double-cliquant une ligne le fichier (s'il est disponible sur l'ordinateur) s'ouvre dans son logiciel par défaut (la ligne ici surlignée correspond au PDF affiché à droite de l'écran). Il gère aussi quelques informations complémentaires, relatives à chacun des fichiers listés (une mini-base de données dans la base de données, en somme).

Tout ça (sauf le composant "DOCS") c'est les fonctions basiques, qu'offrait par exemple ClarisWorks il y a au moins 30 ans.

Le reste, sur les bases de données modernes, est invisible (donc peu utile dans un cas simple comme ici), lourd à traiter pour l'ordinateur, et exposé à des piratages.
Car l'objectif général de ces bases de données est de pouvoir les consulter à distance, éventuellement à l'aide de logiciels quelconques (qui utilisent alors un langage normalisé, couramment SQL). Les données résident alors sur l'un des postes du réseau, sur un cloud, ou allez savoir où... Si plusieurs postes accèdent simultanément à la même fiche, il ne faudrait pas que les deux essaient de la modifier en même temps ! Ce qui impose une procédure de synchronisation...
Mais pour un petit catalogue personnel, on n'a pas besoin de ce fâtras ; et ce dont on n'a pas besoin, est toujours trop lourd à porter !

Certains en sont vraiment à faire des requêtes style "SELECT * FROM fusils WHERE fusils.type = 'mauser'" ?!
Je veux dire, bon si la collection concerne 10 000 objets why not, mais pour une centaine d'armes.... Même pas sûr qu'un musée voit un intérêt autre que dans un fichier excel bien organisé.

Ça peut être assez fun, le SQL.

Par exemple, ceci me dénombre tout ce que j'ai par catégorie :

Caym a écrit:Certains en sont vraiment à faire des requêtes style "SELECT * FROM fusils WHERE fusils.type = 'mauser'" ?!
Je veux dire, bon si la collection concerne 10 000 objets why not, mais pour une centaine d'armes.... Même pas sûr qu'un musée voit un intérêt autre que dans un fichier excel bien organisé.

S'il y a plusieurs dizaines de fiches, un système de recherche peut éviter de les faire défiler une à une pour trouver la bonne ; ou sélectionner toutes les armes du même calibre ; et un système de tri peut permettre de classer les Berthier par numéros de série...

Pour les recherches, la rédaction d'une requête SQL m'avait parue bien rébarbative alors j'avais adopté le système de ClarisWorks, que j'utilisais régulièrement : le mode recherche affiche une fiche vide, et on tape le critère dans le champ où on veut le trouver. Si on tape des critères dans plusieurs champs, ça fait une recherche ET.
Mais ça m'a vite paru un peu insuffisant, alors j'ai ajouté des coches :
- définissant la portée de la recherche (sur toutes les fiches ou sur la sélection déjà réalisée, en ce cas c'est une recherche ET),
- ajoutant le résultat à la sélection déjà réalisée (ce qui donne une recherche OU),
- excluant le critère (recherche NON ; qu'en fait je n'utilise jamais),
- ignorer les majuscules, ignorer les espaces, "mot complet" (c'est des options usuelles).
Plus un champ spécial pour taper un critère à rechercher dans n'importe quel champ...
Manque encore une coche pour ignorer les accents, cédilles et lettres collées.

Pour classer des documents cette base de données s'avère bien utile (surtout pour retrouver un document dont on se souvient de quelques points marquants, qui logiquement doivent être notés sur la fiche).
Par contre, pour une collection c'est effectivement peut-être superflu. Mais si on a le logiciel et qu'on l'utilise déjà pour d'autres choses, c'est presque plus simple ; et ça évite de chopper la migraine, qui vient vite quand on s'abrutit sur les colonnes toujours trop étroites d'un tableur.