SQLite ist ein von der US Library of Congress empfohlenes Speicherformat

 (sqlite.org)
1 Punkte von GN⁺ 1 시간 전 | 1 Kommentare | Auf WhatsApp teilen

SQLite und die empfohlenen Speicherformate der LoC

Bewertungskriterien für empfohlene Speicherformate

  • Empfohlene Speicherformate sind Formate, von denen die Erhaltungsexperten der Library of Congress annehmen, dass sie die Überlebensfähigkeit und den dauerhaften Zugang digitaler Inhalte maximieren
  • Bei der Auswahl empfohlener Speicherformate berücksichtigt die Library of Congress die folgenden Kriterien

  • Offenheit

    • Bewertet wird, inwieweit vollständige Spezifikationen und Werkzeuge zur Prüfung der technischen Integrität vorhanden und für die Personen zugänglich sind, die digitale Inhalte erstellen und pflegen
    • Vollständige Dokumentation ist wichtiger als die Anerkennung durch ein standardisierendes Gremium

  • Verbreitung

    • Bewertet wird, in welchem Maß wichtige Ersteller, Verbreiter und Nutzer von Informationsressourcen das jeweilige Format bereits verwenden
    • Dazu zählen Verwendungen als Master-Format, Endnutzer-Auslieferungsformat und Mittel zum Austausch zwischen Systemen

  • Transparenz

    • Bewertet wird, inwieweit sich die digitale Darstellung mit grundlegenden Werkzeugen direkt analysieren lässt, etwa ob sie in einem reinen Texteditor für Menschen lesbar ist

  • Selbstdokumentation

    • Selbstdokumentierende digitale Objekte enthalten grundlegende beschreibende Metadaten, technische Metadaten und weitere administrative Metadaten

  • Externe Abhängigkeiten

    • Bewertet wird, in welchem Maß Rendering oder Nutzung von bestimmter Hardware, Betriebssystemen oder Software abhängen und wie komplex der Umgang mit diesen Abhängigkeiten in künftigen Technologieumgebungen ist

  • Patenteinflüsse

    • Bewertet wird, inwieweit Patente die Fähigkeit von Erhaltungseinrichtungen behindern, Inhalte in diesem Format zu bewahren

  • Technische Schutzmechanismen

    • Bewertet wird, ob Mechanismen wie Verschlüsselung implementiert sind, die die Bewahrung von Inhalten in vertrauenswürdigen Repositorien verhindern

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 시간 전
Hacker-News-Kommentare

  • Ich lasse mich immer wieder von SQLite inspirieren. Insgesamt mag ich es sehr, aber wenn man nicht schreibt, ist es auch eine ziemlich überdimensionierte Wahl
    Deshalb habe ich zwar nichts gebaut, das SQLite ablöst, aber ein Format, das viel leichter und schneller ist und auch auf zstd-komprimierten Dateien funktioniert. Die Indizes sind sehr klein und es kann wie SQLite Binärdaten oder Text enthalten
    Der wasm-Teil für Dekomprimierung, Lesen und Suchen ist 38 KB unkomprimiert, mit gzip vermutlich etwa 16 KB. Verglichen mit den 1,2 MB für SQLite-Wasm plus Glue-Code sind das 3 % der Größe, und Suche sowie Laden sind deutlich schneller
    Mein Programm ist nicht spaltenorientiert und nicht für die Verwaltung von Tabellenkalkulationen geeignet, aber für Wörterbücher und Archive aus Bild- und Audiodateien passt es gut
    Ich habe außerdem einen jbig2-Decoder als 17-KB-Wasm-Modul portiert, sodass sich schwarzweiße Scans mit 8 KB pro Seite lesen lassen und trotzdem noch erkennbar sind
    https://github.com/tnelsond/peakslab
    SQLite ist sehr gut entworfen, PeakSlab ist sehr einfach

    • Du sagst „1,2 MB für SQLite-Wasm und Glue-Code“, aber die aktuelle Standardform im trunk, unminifiziert, ist in Wirklichkeit 1,7 MB. Fast genauso viel davon ist Dokumentation wie JS-Code, daher ist es ungefähr halb WASM, halb JS. Minifiziert stimmen die 1,2 MB aber
      Nebenbei: Ich bin der Maintainer
      Die aktuellen trunk-Zahlen sind sqlite3.wasm 896745, sqlite3.mjs 816270 (unminifiziert mit Doku), sqlite3.mjs 431388 (unminifiziert ohne Doku), sqlite3.mjs 310975 (minifiziert)
    • PeakSlab kannte ich nicht, aber das ist wirklich cool und neuartig. Die Wörterbuch-Performance scheint auch hervorragend zu sein, definitiv etwas zum Bookmarken für später
    • Das wirkt eher wie ein Konkurrent zu Berkeley DB von früher: https://en.wikipedia.org/wiki/Berkeley_DB
      Wie ich gerade sehe, hat es nicht einmal mehr eine BSD-Lizenz, und ohnehin ist es durch SQLite fast verdrängt worden, aber als grundlegender schlüssel-wertbasierter Speicher auf Festplatte wurde es verwendet
    • SQLite selbst ist durchaus einfach, und mir gefallen die Designprinzipien seines SQL-Dialekts
      So nach dem Motto: „Ein Right Join ist nur ein Left Join in die andere Richtung, also brauchen wir das nicht“
      Natürlich kann man immer etwas Einfacheres oder Spezialisierteres bauen. Viele Apps, die eine Datenbank nutzen, würden mit SQLite völlig gut laufen, und manche Apps kämen vermutlich sogar mit Textdateien statt einer Datenbank wie SQLite aus
    • Die standardnähere Lösung wäre wohl cdb. Komprimierte Daten unterstützt es allerdings nicht
      https://cdb.cr.yp.to/ , https://en.wikipedia.org/wiki/Cdb_(software)

  • Ich mochte SQLite schon immer, aber ich habe gehört, dass manche Unternehmen seinen Einsatz verbieten
    Der Grund ist, dass man damit viel zu leicht eine Datenbank für eine App bauen kann, sodass ein zentraler Kernbestandteil der Anwendung einfach wie eine Datei aussieht. Diese Datei kann jede beliebige Endung haben und auf andere Server kopiert werden. Das gilt auch dann, wenn sie personenbezogene Daten enthält
    Wenn man sich vorstellt, dass sich das über so viele Apps vervielfacht, wie ein Unternehmen eben hat, kann das ein ziemliches Chaos werden
    DevOps- und DBA-Teams bevorzugen Datenbanken als große, schwere Systeme, die für jeden offensichtlich Datenbankserver sind. Schon die Verbindung dorthin ist klar sichtbar und so weiter
    Trotzdem mag ich SQLite immer noch

    • Dann würde mich interessieren, ob dieselben Unternehmen auch Excel verbieten. Excel-Tabellen werden an unerwarteten Orten oft zu Schatten-Datenbanken
    • Für das Gespräch „Alles kann zu einer mission-kritischen Datenbank werden“ sollte dieser Beitrag Pflichtlektüre sein
      https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_...
    • Wenn es eine Datei mit beliebiger Endung ist, muss man eben die Magic Number lesen. Dateiendungen sollte man sowieso nicht vertrauen
      Und „kann auf einen anderen Server kopiert werden“ gilt für Tabellenkalkulationen genauso
      Ich will nicht bestreiten, dass zentralisierter Datenzugriff wünschenswert ist, aber die Argumentation wirkt nicht besonders ausgereift
    • SQLite hat auch solche interessante Nutzung: https://sqlite.org/sqlar.html
    • Deshalb legt man solche Konfigurationsdateien in AppData oder ein dotfile-Verzeichnis, oder auf MacOS an die entsprechende Stelle in ~/Library

  • Früher dachte ich: „SQLite ist ein Spielzeugprodukt und für echte Daten nicht vertrauenswürdig“, inzwischen bin ich eher bei „Lasst uns SQLite für fast alles verwenden“
    Wenn man zum Muster ein Schreiber, viele Leser passt, ist SQLite großartig. Mit den richtigen Einstellungen verliert man keine Daten, und diese Einstellungen findet man mit einer Minute Suche
    Die meisten meiner Apps bestehen heute einfach aus einer Go-Binärdatei + SQLite + einer systemd-Service-Datei
    Ich habe noch nie Daten verloren, die Performance ist hervorragend, und für die meisten Apps reicht es vollkommen

    • Ein einzelner Schreiber ist in der Praxis gar nicht so problematisch, wie oft behauptet wird. Moderne NVMe-Laufwerke sind enorm leistungsfähig; mit optimierten WAL-Einstellungen sind 5.000 Schreibvorgänge pro Sekunde leicht drin. Für die meisten Apps ist das jenseits jeder Vorstellung
      Sogar auf einem gewöhnlichen VPS habe ich mit einem Batch-Writer-Muster schon 180.000 Schreibvorgänge pro Sekunde erreicht
    • Mich würde interessieren, ob du mehrere Backend-Knoten verwendest. Falls ja, wie greifst du dann von verschiedenen Knoten auf die SQLite-Datei zu?

  • Da steht „Zum Zeitpunkt des Schreibens dieses Beitrags (2018-05-29) …“, also ist das fast 8 Jahre alt. Ich beschwere mich nicht, weil ich es bis jetzt nicht kannte, eher danke fürs Posten
    Mein mathematisches Gehirn hatte kurz einen Aussetzer und hielt es für 6 Jahre

    • Es ist jetzt 2026, also sind es 8 Jahre
    • Beim Lesen hatte ich ein Déjà-vu

  • Empfohlenes Speicherformat 2026: https://www.loc.gov/preservation/resources/rfs/data.html

    • Wenn man Daten speichert und dabei 300 bis 500 Jahre vorausplant, damit sie alle möglichen Innovationen und ganz normale technische Alterung überstehen, braucht man wirklich langfristiges Denken
      Was ist wohl das haltbarste papierbasierte Medium?
    • Die Empfehlungskriterien wirken ziemlich locker. XLS ist als „bevorzugt“ aufgeführt

  • Für die Archivierung von Daten im öffentlichen Sektor könnte SQLite eine der besten Optionen sein
    Die Spezifikation ist offen, es ist weit verbreitet, und die Wahrscheinlichkeit ist hoch, dass man es auch in Zukunft noch lesen kann
    Es hängt wenig von einem bestimmten Betriebssystem oder Dienst ab, und auch das Patentrisko ist gering
    Aus Sicht der langfristigen Beständigkeit ist es sehr wichtig, nicht von einem bestimmten Unternehmen oder Dienst abhängig zu sein

    • Archivarinnen und Archivare mögen auch Formate, die dem Original nahekommen. SQLite kann relationale Beziehungen so erhalten, wie sie sind, was sich in CSV nur schwer ausdrücken lässt

  • Ich mag SQLite und freue mich, dass das geteilt wurde, aber am Ende des Titels sollte wohl „(2018)“ stehen
    Dort steht: „Zum Zeitpunkt des Schreibens dieses Beitrags (2018-05-29) sind die anderen empfohlenen Speicherformate für Datensätze nur XML, JSON und CSV“

    • Zur Einordnung: Danach wurden der Liste viele Formate hinzugefügt
      Bei den bevorzugten Formaten werden plattformunabhängige textbasierte Formate gegenüber nativen oder binären Formaten bevorzugt, solange die Daten vollständig bleiben und Details sowie Genauigkeit erhalten. Dazu zählen gut entwickelte und breit angenommene De-facto-Marktstandards
      Beispiele sind bekannte schema-basierte Formate mit offenen Validierungswerkzeugen, zeilenorientierte Formate wie TSV, CSV und Fixed-Width sowie plattformunabhängige offene Formate wie .db, .db3, .sqlite und .sqlite3
      Dazu kommen proprietäre Formate, die in bestimmten Berufsgruppen De-facto-Standard sind oder von mehreren Werkzeugen unterstützt werden, etwa Excel .xls/.xlsx oder Shapefile
      Bei Zeichencodierungen werden UTF-8, UTF-16 mit BOM, US-ASCII und ISO 8859-1 bevorzugt, danach andere benannte Encodings
      Als zulässige Formate gelten bei Daten nichtproprietäre, offene, dokumentierte Formate, die von Fachgemeinschaften oder Regierungsstellen als Standard anerkannt sind (CDF, HDF usw.), sowie textbasierte Datenformate mit verfügbarem Schema
      Für Bündelung oder Transfer sind ZIP, RAR, tar und 7z zulässig, sofern sie keine Verschlüsselung, kein Passwort und keine anderen Schutzmechanismen enthalten
      https://www.loc.gov/preservation/resources/rfs/data.html

  • Ich dachte erst gestern noch, dass es schon eine Weile her sei, seit ich oben auf HN einen SQLite-Beitrag gesehen habe
    Ich mag die Einfachheit und Geschwindigkeit von SQLite wirklich sehr und habe es sowohl in privaten als auch in beruflichen Projekten verwendet
    Im Arbeitsalltag lande ich am Ende aber doch oft bei Excel. Nicht weil ich Excel lieber mag, sondern weil es so weit verbreitet ist und daher beim Teilen und Erkunden von Datensätzen mit weniger technischen Stakeholdern oder Führungskräften den geringsten Reibungsverlust verursacht

    • Ich glaube nicht, dass dadurch plötzlich dein Weltbild zusammenbricht, aber vielleicht ist es trotzdem nützlich, weil es mir selbst geholfen hat: Schau dir Metabase an
      Man kann es selbst hosten, und wenn du Daten Stakeholdern einfach nur in gut konsumierbarer Form zeigen willst, ist es wirklich simpel. Klar, wenn man zu tief einsteigt, kann man anfangen, jede Entscheidung seines Lebens zu bereuen, aber ich versuche, mich davon fernzuhalten
      https://www.metabase.com/
    • Mich hat an SQLite immer gestört, dass es auf Text-Parsing angewiesen ist. Warum muss man Abfragen als Text schreiben, statt sie als Programmlogik auszudrücken?
      Deshalb habe ich relationale Datenbanken nie benutzt. Ich mag sie einfach nicht. Ich verstehe, dass sie performanter sein können als rein strukturierte Daten, aber ich mag SQL und die ganze Idee von SQL nicht und will nichts schreiben, lernen oder benutzen, das davon abhängt
      Es fühlt sich so falsch an wie PHP. Gibt es irgendeine Möglichkeit, das abzumildern? Ich möchte SQLite nicht wegen SQL immer wieder aufgeben, aber ich kann mich einfach nicht damit anfreunden. Es stört mich, Strings zu bauen oder überhaupt String-Parsing irgendwo im Stack zu haben; es fühlt sich einfach falsch an

  • SQLite ist erstaunlich vielseitig. Erst vor ein paar Wochen wurde eine Erweiterung veröffentlicht, die in SQLite Interprozess-Queues, Streams, Publish/Subscribe und Ähnliches implementiert
    Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite | 327 points | 94 comments | https://news.ycombinator.com/item?id=47874647
    Echtzeit-Benachrichtigungen waren eines der großen fehlenden Puzzleteile, wenn man eine komplette App auf einem SQLite-Backend bauen wollte; jetzt gibt es dafür eine ziemlich gute Lösung

  • Es ist schön zu sehen, dass SQLite diese Art von institutioneller Anerkennung bekommt. Durch das Ein-Datei-Format wird Archivspeicherung im Vergleich zu traditionellen Datenbank-Dumps enorm vereinfacht