SQLiteは米国議会図書館の推奨保存形式
(sqlite.org)- SQLite は、米国議会図書館 がデータセット向けに推奨する保存形式に含まれている
- 関連する根拠は、議会図書館の SQLite 形式の説明 とデータ向け推奨形式一覧で確認できる: https://www.loc.gov/preservation/digital/formats/fdd/fdd000461.shtml#local, https://www.loc.gov/preservation/resources/rfs/data.html
- 2018年5月29日時点で、データセット用の推奨保存形式は SQLite のほか XML、JSON、CSV のみ
- 議会図書館の推奨保存形式とは、保存の専門家がデジタルコンテンツの 存続可能性 と 継続的なアクセス性 を最大化できるとみなす形式
- 判断基準には、公開性、採用度、透明性、自己文書化、外部依存性、特許の影響、暗号化のような技術的保護メカニズムが含まれる
SQLiteとLoCの推奨保存形式
- SQLite は、米国議会図書館 の基準で、データセット向けの推奨保存形式に含まれている
- 関連する根拠は、議会図書館の SQLite 形式の説明とデータ向け推奨形式一覧で確認できる
- 2018年5月29日時点で、データセット用の推奨保存形式は SQLite のほか XML、JSON、CSV のみ
推奨保存形式の判断基準
- 推奨保存形式とは、議会図書館の保存専門家が、デジタルコンテンツの 存続可能性 と 継続的なアクセス性 を最大化できると考える形式
- 議会図書館は、推奨保存形式を選ぶ際に次の基準を考慮する
-
公開性
- 技術的完全性を検証するための完全な仕様とツールが存在し、デジタルコンテンツを作成・維持する人々がそれらにアクセスできる度合いを見る
- 認定された標準化機関の承認よりも、完全な文書化 のほうが重要
-
採用度
- 情報資源の主要な作成者、配布者、利用者が、すでにその形式を使用している度合いを見る
- マスター形式、最終利用者向け配信形式、システム間の交換手段として使われる場合が含まれる
-
透明性
- テキスト専用エディタで人間が読めるかどうかのように、基本的なツールでデジタル表現を直接分析できる度合いを見る
-
自己文書化
- 自己文書化されたデジタルオブジェクトは、基本的な説明メタデータ、技術メタデータ、その他の管理メタデータを含む
-
外部依存性
- 特定のハードウェア、OS、ソフトウェアへのレンダリングや利用の依存度と、将来の技術環境でその依存性に対処する複雑さを見る
-
特許の影響
- 特許が、保存機関による当該形式コンテンツの維持能力を妨げる度合いを見る
-
技術的保護メカニズム
- 信頼できる保存リポジトリでのコンテンツ保存を妨げる、暗号化のようなメカニズムが実装されているかを見る
1件のコメント
Hacker Newsのコメント
SQLiteにはいつも刺激を受けている。全体としては好きだが、書き込みをしないならかなり大げさな選択でもある
なのでSQLiteを超えるものではないけれど、もっと 軽量で高速で、zstd圧縮ファイル上でも動く形式を作った。インデックスはとても小さく、SQLiteのようにバイナリやテキストを格納できる
展開・読み取り・検索を担当するwasm部分は、非圧縮で38KB、gzipならたぶん16KBくらい。SQLiteのwasmとグルーコードの1.2MBと比べると3%のサイズで、検索と読み込みはずっと速い
私のプログラムは列指向でもなければスプレッドシート管理にも向いていないが、辞書と画像・音声ファイルのアーカイブにはよく合う
jbig2デコーダも17KBのwasmモジュールに移植していて、ページあたり8KBの白黒スキャンも読めて、しかもまだ十分判読できる
https://github.com/tnelsond/peakslab
SQLiteは非常によく設計されていて、PeakSlabはとても単純だ
ちなみに私がそのメンテナだ
現在のtrunk基準の数値は sqlite3.wasm 896745、sqlite3.mjs 816270（ドキュメント込み非縮小）、sqlite3.mjs 431388（ドキュメント抜き非縮小）、sqlite3.mjs 310975（縮小）
今見たらもうBSDライセンスですらないし、とにかくSQLiteのせいでほぼ消えたが、基本的なディスクベースのキー・バリューストア用途で使われていた
「右結合は向きが逆なだけの左結合だから、そんなものは要らない」みたいな感じだ
もちろん、もっと単純なものやもっと特化したものは常にあり得る。データベースを使う多くのアプリはSQLiteだけで十分うまく動くだろうし、アプリによってはSQLiteのようなDBの代わりに テキストファイル だけで十分かもしれない
https://cdb.cr.yp.to/ , https://en.wikipedia.org/wiki/Cdb_(software)
SQLiteは昔から好きだが、利用を禁止している会社もあると聞いた
理由は、アプリ用データベースをあまりに簡単に作れてしまうので、アプリケーションの超中核コンポーネントがただのファイルのように見えてしまうからだ。そのファイルはどんな拡張子にもできるし、別のサーバーにコピーすることもできる。その中に 個人識別情報 が入っていても同じだ
これが社内のアプリの数だけ増えると考えると、かなりのカオスになり得る
DevOpsやDBAチームは、データベースが誰の目にも明らかな大きく重いデータベースサーバーであることを好む。接続するという行為も明確に見えるし、などなど
それでもSQLiteはやはり好きだ
https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_...
「別のサーバーにコピーできる」というのはスプレッドシートでも同じだ
集中化されたデータアクセスが望ましいこと自体は否定しないが、その理屈は十分に洗練されているようには見えない
昔は「SQLiteはおもちゃ製品で、本番データには信頼できない」と思っていたが、今では「ほぼ何にでもSQLiteを使おう」という側に変わった
単一ライター・複数リーダー のパターンに合わせられるなら、SQLiteはとても良い。正しい設定さえ使えばデータを失わないし、その設定も1分ほど検索すれば分かる
最近の自分のアプリの大半は、単なるGoバイナリ + SQLite + systemdサービスファイルという組み合わせだ
まだ一度もデータを失ったことはなく、性能も素晴らしく、ほとんどのアプリには十分だ
しかも普通のVPSで、バッチライターパターンを使って毎秒18万書き込みもやったことがある
「この記事を書いている時点（2018-05-29）…」とあるので、ほぼ8年前の話だ。それでも今まで知らなかったので不満ではなく、むしろ投稿してくれてありがたい寄りだ
数学脳が一瞬バグって6年だと勘違いしていた
2026年の推奨保存形式: https://www.loc.gov/preservation/resources/rfs/data.html
最も長く生き残った紙媒体は何だろう？
公共部門のデータ保存において、SQLiteは最良の選択肢の1つかもしれない
仕様が公開されており、広く採用され、今後も読める可能性が高い
特定のOSやサービスへの依存が小さく、特許リスク も低い
長期的な持続性という観点では、特定の企業やサービスに依存しないことが非常に重要だ
SQLiteが好きで共有してくれたのはうれしいが、タイトルの末尾には「(2018)」を付けるべきだと思う
「この記事を書いている時点（2018-05-29）では、データセット向けに推奨される他の保存形式はXML、JSON、CSVだけだ」と書かれている
preferred formatsとしては、データが完全で詳細と精度を維持している限り、ネイティブ形式やバイナリ形式よりもプラットフォーム非依存の文字ベース形式が優先される。十分に開発され広く採用された事実上の市場標準も含まれる
たとえば、公開された検証ツールがあるよく知られたスキーマベース形式、TSV・CSV・固定長のような行指向形式、.db・.db3・.sqlite・.sqlite3 のようなプラットフォーム非依存のオープン形式がある
また、特定職種での事実上の標準、あるいは複数ツールが対応する独自形式も含まれる。たとえばExcel .xls/.xlsx や Shapefile のようなものだ
文字エンコーディングは UTF-8、BOM付きUTF-16、US-ASCII、ISO 8859-1、その他の名前付きエンコーディングの順で好まれる
acceptable formatsとしては、データについては専門コミュニティや政府機関が標準として承認した非独占的で公開文書化された形式（CDF、HDFなど）、利用可能なスキーマを持つテキストベースのデータ形式がある
束ねたり転送したりする用途では、暗号化・パスワード・その他の保護機構のない ZIP、RAR、tar、7z が許容される
https://www.loc.gov/preservation/resources/rfs/data.html
ちょうど昨日も、HNのトップでSQLiteの記事を見てからしばらく経ったなと思っていた
SQLiteの 単純さと速さ が本当に好きで、個人プロジェクトでも仕事のプロジェクトでも使ってきた
それでも日常業務では結局Excelに行き着く。Excelの方が好きだからではなく、あまりに広く使われているので、技術寄りでないステークホルダーや役員とデータセットを共有して探索するときに 摩擦が最も少ない方法 だからだ
セルフホストできるし、ステークホルダーにデータを消化しやすい形で見せるだけなら本当にシンプルだ。もちろん深くハマりすぎると人生のあらゆる決断を後悔するかもしれないが、自分はそうならないよう自制している
https://www.metabase.com/
このせいでリレーショナルデータベースを一度も使ったことがない。嫌いだからだ。純粋な構造化データより性能が良くなり得ることは分かっているが、SQLと、SQLという発想そのものが嫌いで、書いたり学んだり、それに依存するシステムを使ったりしたくない
PHPレベルで間違ったアプローチのように感じる。これを和らげる方法はあるだろうか？ SQLのせいでSQLiteを諦め続けたくはないが、どうしても受け入れられない。文字列を組み立てたり、スタックのどこかに文字列パースが入るのが嫌で、とにかく間違っている感じがする
SQLiteは驚くほど多才だ。ほんの数週間前にも、SQLite上で プロセス間キュー、ストリーム、pub/sub などを実装する拡張が公開されたばかりだ
Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite | 327 points | 94 comments | https://news.ycombinator.com/item?id=47874647
リアルタイム通知は、SQLiteバックエンドでアプリ全体を実装する際に欠けていた大きなピースの1つだったが、今ではかなり良い解決策がある
SQLiteがこのレベルの 機関的なお墨付き を得ているのを見るのはうれしい。単一ファイル形式のおかげで、従来のデータベースダンプよりアーカイブ保存が圧倒的に簡単になる