SQLite fait partie des formats de stockage recommandés par la Bibliothèque du Congrès des États-Unis

 (sqlite.org)
1 points par GN⁺ 1 시간 전 | 1 commentaires | Partager sur WhatsApp
  • SQLite figure parmi les formats de stockage recommandés par la Bibliothèque du Congrès des États-Unis pour les jeux de données
  • Les références correspondantes sont disponibles dans la description du format SQLite de la Library of Congress ainsi que dans la liste des formats de données recommandés : https://www.loc.gov/preservation/digital/formats/fdd/fdd000461.shtml#local, https://www.loc.gov/preservation/resources/rfs/data.html
  • Au 29 mai 2018, les formats de stockage recommandés pour les jeux de données, en dehors de SQLite, sont uniquement XML, JSON et CSV
  • Les formats de stockage recommandés par la Library of Congress sont ceux que les spécialistes de la préservation estiment les plus à même de maximiser la pérennité et l’accessibilité continue des contenus numériques
  • Les critères d’évaluation incluent l’ouverture, l’adoption, la transparence, l’auto-documentation, les dépendances externes, l’impact des brevets et les mécanismes de protection technique comme le chiffrement

SQLite et les formats de stockage recommandés par la LoC

Critères d’évaluation des formats de stockage recommandés

  • Les formats de stockage recommandés sont ceux que les spécialistes de la préservation de la Library of Congress considèrent comme les plus aptes à maximiser la pérennité et l’accessibilité continue des contenus numériques
  • La Library of Congress prend en compte les critères suivants pour sélectionner les formats de stockage recommandés

  • Ouverture

    • Il s’agit d’évaluer dans quelle mesure il existe des spécifications et des outils complets permettant de vérifier l’intégrité technique, et dans quelle mesure les personnes qui créent et maintiennent les contenus numériques peuvent y accéder
    • Une documentation complète est jugée plus importante que l’approbation d’un organisme de normalisation reconnu

  • Adoption

    • Il s’agit d’évaluer dans quelle mesure les principaux créateurs, diffuseurs et utilisateurs de ressources informationnelles utilisent déjà ce format
    • Cela inclut les cas où il est utilisé comme format maître, format de diffusion pour l’utilisateur final ou moyen d’échange entre systèmes

  • Transparence

    • Il s’agit d’évaluer dans quelle mesure la représentation numérique peut être analysée directement avec des outils de base, par exemple si elle est lisible par un humain dans un éditeur de texte brut

  • Auto-documentation

    • Un objet numérique auto-documenté contient des métadonnées descriptives de base, des métadonnées techniques et d’autres métadonnées administratives

  • Dépendances externes

    • Il s’agit d’évaluer le degré de dépendance au rendu ou à l’utilisation vis-à-vis d’un matériel, d’un système d’exploitation ou d’un logiciel spécifique, ainsi que la complexité de gestion de cette dépendance dans les environnements technologiques futurs

  • Impact des brevets

    • Il s’agit d’évaluer dans quelle mesure les brevets peuvent entraver la capacité des institutions de préservation à maintenir les contenus dans ce format

  • Mécanismes de protection technique

    • Il s’agit d’évaluer si des mécanismes comme le chiffrement sont mis en œuvre et s’ils empêchent la préservation des contenus dans des dépôts fiables

À lire aussi

1 commentaires

 
GN⁺ 1 시간 전
Commentaires sur Hacker News

  • SQLite m’inspire toujours. J’aime beaucoup l’ensemble, mais si on n’écrit pas, c’est aussi un choix assez excessif
    Du coup, sans prétendre dépasser SQLite, j’ai créé un format bien plus léger, plus rapide, qui fonctionne aussi avec des fichiers compressés en zstd. L’index est très petit et, comme SQLite, il peut contenir du binaire ou du texte
    La partie wasm qui gère la décompression, la lecture et la recherche fait 38 KB en non compressé, probablement autour de 16 KB en gzip. Comparé aux 1,2 MB du wasm de SQLite et de son glue code, ça représente 3 % de la taille, et la recherche comme le chargement sont bien plus rapides
    Mon programme n’est pas orienté colonnes et n’est pas adapté à la gestion de feuilles de calcul, mais il convient bien aux dictionnaires et aux archives d’images ou de fichiers audio
    J’ai aussi porté un décodeur jbig2 en module wasm de 17 KB, ce qui permet de lire des scans noir et blanc de 8 KB par page tout en restant lisibles
    https://github.com/tnelsond/peakslab
    SQLite est très bien conçu, et PeakSlab est très simple

    • Tu parles de « 1,2 MB pour le wasm de SQLite et le glue code », mais dans la trunk actuelle, la forme standard non réduite fait en réalité 1,7 MB. La doc prend presque autant de place que le code JS, donc le WASM et le JS sont à peu près moitié-moitié. Cela dit, une fois réduit, 1,2 MB est bien le bon chiffre
      Pour info, j’en suis le mainteneur
      Dans la trunk actuelle, on a sqlite3.wasm 896745, sqlite3.mjs 816270 (non réduit avec documentation), sqlite3.mjs 431388 (non réduit sans documentation), sqlite3.mjs 310975 (réduit)
    • Je ne connaissais pas PeakSlab, mais c’est vraiment cool et nouveau. Les performances sur les dictionnaires ont aussi l’air excellentes, ça vaut le coup de le mettre en favori pour y revenir plus tard
    • Ça a l’air plus proche d’un concurrent de l’ancien Berkeley DB : https://en.wikipedia.org/wiki/Berkeley_DB
      Je vois qu’aujourd’hui ce n’est même plus sous licence BSD et, de toute façon, SQLite l’a pratiquement fait disparaître, mais il servait comme stockage clé-valeur basique sur disque
    • SQLite est lui aussi assez simple, et j’aime bien les principes de conception de son dialecte SQL
      Le genre de logique « une jointure droite n’est qu’une jointure gauche dans l’autre sens, donc on n’en a pas besoin »
      Bien sûr, on peut toujours faire plus simple ou plus spécialisé. Beaucoup d’apps qui utilisent une base de données tourneront très bien avec SQLite seul, et pour certaines apps, de simples fichiers texte suffiraient probablement à la place d’une base comme SQLite
    • Une solution plus standard serait sans doute cdb. En revanche, il ne gère pas les données compressées
      https://cdb.cr.yp.to/ , https://en.wikipedia.org/wiki/Cdb_(software)

  • J’ai toujours aimé SQLite, mais j’ai entendu dire que certaines entreprises en interdisaient l’usage
    La raison, c’est que ça permet de créer trop facilement une base de données d’application, au point qu’un composant ultra central de l’application peut juste ressembler à un fichier. Ce fichier peut avoir n’importe quelle extension et peut aussi être copié vers un autre serveur. Même s’il contient des données personnelles identifiables, ça ne change rien
    Si on imagine ça multiplié par le nombre d’apps dans une entreprise, ça peut vite devenir un beau bazar
    Les équipes DevOps et DBA préfèrent que les bases de données soient de grosses machines lourdes, clairement identifiables comme des serveurs de base de données. Le simple fait de s’y connecter est explicite, etc.
    Cela dit, j’aime toujours SQLite

    • Dans ce cas, je me demande si les mêmes entreprises interdisent aussi Excel. Les feuilles Excel deviennent souvent des bases de données de l’ombre à des endroits inattendus
    • Pour toute discussion du type « n’importe quoi peut devenir une base de données critique », il faut absolument lire ce post
      https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_...
    • Si c’est « un fichier qui peut avoir n’importe quelle extension », il suffit de lire le magic number. De toute façon, il ne faut jamais faire confiance à l’extension d’un fichier
      Quant au fait qu’il « puisse être copié vers un autre serveur », c’est tout aussi vrai pour une feuille de calcul
      Je ne nie pas qu’un accès centralisé aux données soit souhaitable, mais l’argument ne me semble pas suffisamment solide
    • SQLite a aussi cet usage intéressant : https://sqlite.org/sqlar.html
    • C’est pour ça qu’on place ce genre de fichiers de configuration dans AppData, dans un répertoire de dotfiles, ou à l’emplacement équivalent sous MacOS dans ~/Library

  • Avant, je pensais que « SQLite est un produit jouet, pas fiable pour de vraies données », mais maintenant je suis plutôt passé au camp du « mettons SQLite partout »
    Si on peut s’adapter au modèle un seul écrivain, plusieurs lecteurs, SQLite est excellent. Avec la bonne configuration, on ne perd pas de données, et cette configuration se trouve avec une minute de recherche
    Aujourd’hui, la plupart de mes apps, c’est juste un binaire Go + SQLite + un fichier de service systemd
    Je n’ai encore jamais perdu de données, les performances sont excellentes, et c’est suffisant pour la majorité des apps

    • Le single writer n’est en pratique pas un problème aussi important qu’on le dit souvent. Les disques NVMe actuels sont incroyables, et avec une configuration WAL optimisée, 5 000 écritures par seconde s’obtiennent facilement. La plupart des apps n’en rêveront jamais
      J’ai même déjà atteint 180 000 écritures par seconde sur un VPS banal avec un modèle de writer par lots
    • Je me demande si tu utilises plusieurs nœuds backend. Si oui, je me demande aussi comment ils accèdent au fichier SQLite depuis des nœuds différents

  • C’est marqué « au moment où cet article est écrit (2018-05-29)… », donc c’est une info qui a presque 8 ans. Cela dit, comme je ne le savais pas jusque-là, ce n’est pas vraiment une plainte, plutôt un merci de l’avoir postée
    Mon cerveau de matheux a brièvement buggé et j’ai cru que ça faisait 6 ans

    • On est en 2026 maintenant, donc ça fait 8 ans
    • J’ai eu une impression de déjà-vu en le lisant

  • Format de stockage recommandé en 2026 : https://www.loc.gov/preservation/resources/rfs/data.html

    • Quand on stocke des données en pensant à 300 à 500 ans, en essayant de résister à toutes sortes d’innovations et à l’obsolescence technique de base, il faut vraiment réfléchir à long terme
      Quel est le support papier qui a survécu le plus longtemps ?
    • Les critères de recommandation ont l’air assez souples. XLS figure parmi les formats « préférés »

  • Pour la préservation des données du secteur public, SQLite pourrait être l’un des meilleurs choix
    Sa spécification est publique, il est largement adopté et il y a de fortes chances qu’on puisse encore le lire à l’avenir
    Il dépend peu d’un système d’exploitation ou d’un service particulier, et le risque de brevet est faible
    Du point de vue de la pérennité à long terme, il est très important de ne pas dépendre d’une entreprise ou d’un service spécifique

    • Les archivistes aiment aussi les formats proches de l’original. SQLite permet de conserver telles quelles des relations relationnelles difficiles à exprimer en CSV

  • J’aime SQLite et je suis content que ce soit partagé, mais il faudrait sans doute ajouter « (2018) » à la fin du titre
    On y lit : « au moment où cet article est écrit (2018-05-29), les seuls autres formats de stockage recommandés pour les jeux de données sont XML, JSON et CSV »

    • Pour info, de nombreux formats ont été ajoutés à la liste depuis
      Parmi les formats préférés, on privilégie les formats textuels indépendants de la plateforme plutôt que les formats natifs ou binaires, à condition que les données soient complètes et conservent les détails et la précision. Cela inclut des standards de marché de facto, bien développés et largement adoptés
      Par exemple, des formats à schéma bien connus avec des outils publics de validation, des formats orientés lignes comme TSV, CSV ou largeur fixe, ainsi que des formats ouverts indépendants de la plateforme comme .db, .db3, .sqlite ou .sqlite3
      Sont également inclus des formats propriétaires devenus des standards de fait dans certaines professions, ou pris en charge par plusieurs outils. Par exemple Excel .xls/.xlsx, ou Shapefile
      Pour l’encodage texte, on préfère UTF-8, UTF-16 avec BOM, US-ASCII ou ISO 8859-1, puis d’autres encodages nommés
      Parmi les formats acceptables, pour les données, on trouve des formats ouverts non propriétaires documentés et validés comme standard par une communauté spécialisée ou une institution publique (CDF, HDF, etc.), ainsi que des formats de données textuels avec schéma disponible
      Pour l’empaquetage ou le transport, ZIP, RAR, tar et 7z sont acceptés s’ils n’ont ni chiffrement, ni mot de passe, ni autre mécanisme de protection
      https://www.loc.gov/preservation/resources/rfs/data.html

  • Juste hier encore, je me disais que ça faisait un moment qu’on n’avait pas vu passer un post SQLite en tête de HN
    J’aime vraiment la simplicité et la rapidité de SQLite, et je l’ai utilisé à la fois pour des projets perso et des projets pro
    Malgré ça, au quotidien, je finis quand même par revenir à Excel. Pas parce que je préfère Excel, mais parce qu’étant tellement répandu, c’est la manière la plus fluide de partager et d’explorer des jeux de données avec des parties prenantes moins techniques ou des dirigeants

    • Je ne pense pas que ça va brusquement faire exploser ta vision du monde, mais puisque ça m’a été utile, ça peut aussi t’aider : ça vaut le coup de jeter un œil à Metabase
      On peut l’auto-héberger, et si tout ce que tu veux, c’est montrer les données à des parties prenantes sous une forme facile à digérer, c’est vraiment simple. Bien sûr, si tu creuses trop, tu pourrais finir par regretter toutes les décisions de ta vie, mais j’essaie de me retenir de ce côté-là
      https://www.metabase.com/
    • Ce qui m’a toujours dérangé avec SQLite, c’est qu’il repose sur le parsing de texte pour fonctionner. Je ne comprends pas pourquoi il faut écrire les requêtes en texte, et pas les exprimer comme de la logique de programme
      C’est pour cette raison que je n’ai jamais utilisé de base de données relationnelle. C’est parce que je déteste ça. Je sais que ça peut être plus performant que des données purement structurées, mais je déteste SQL et l’idée même de SQL, et je n’ai pas envie de l’écrire, de l’apprendre, ni d’utiliser des systèmes qui en dépendent
      Ça me semble aussi fondamentalement mauvais que PHP. Est-ce qu’il y a un moyen d’atténuer ça ? Je n’ai pas envie de continuer à renoncer à SQLite à cause de SQL, mais je n’arrive vraiment pas à l’accepter. Je déteste fabriquer des chaînes, ou avoir du parsing de chaînes à n’importe quel endroit de la stack, ça me semble juste faux

  • SQLite est étonnamment polyvalent. Il y a encore quelques semaines, on a vu sortir une extension SQLite qui implémente des files inter-processus, des streams et du publish/subscribe
    Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite | 327 points | 94 comments | https://news.ycombinator.com/item?id=47874647
    Les notifications en temps réel étaient l’un des gros éléments manquants pour implémenter une application entière sur un backend SQLite, et il existe maintenant une solution plutôt correcte

  • Ça fait plaisir de voir SQLite bénéficier à ce niveau d’une reconnaissance institutionnelle. Son format en fichier unique rend l’archivage énormément plus simple que les dumps de base de données traditionnels