SQLite Part.10

**NAME IS NULL** · 2012/08/16(木) 21:54:16.20

組み込み型データベース SQLite について語るスレッドです。

SQLite
http://www.sqlite.org/

・C/C++ API
　http://www.sqlite.org/c3ref/intro.html

・Syntax
　http://www.sqlite.org/lang.html

・Limits
　http://www.sqlite.org/limits.html

・Support
　http://www.sqlite.org/support.html

**879** · 2022/05/14(土) 17:14:23.65

勘違いだった　全然できてなかった・・

**NAME IS NULL** · 2022/05/15(日) 06:48:52.51

ちんちんシュッ!シュッ!シュッ!

**NAME IS NULL** · 2022/05/21(土) 05:13:32.36

sqlite4は結局どうなったんや

**NAME IS NULL** · 2022/05/21(土) 06:49:31.01

成果はsqlite3に取り込まれて終了

**NAME IS NULL** · 2022/05/22(日) 01:43:04.34

>>884
サンクス

**NAME IS NULL** · 2022/08/10(水) 11:02:53.87

SQLiteを優先順位付きのキューとして使うのは良いことでしょうか

複数のプロセス（CとかPHPとかbashとか）からのメッセージを
別のひとつのプロセスがそこそこのタイミングで受け取りたい
（毎秒チェックで許されるくらい）

**NAME IS NULL** · 2022/08/28(日) 16:18:07.78

>>886
良いことか悪いことかは主観によるので何とも。

実現可能性、という観点でいくと、FAQによれば、

https://www.sqlite.org/faq.html#q19
　SQLiteがHDDへのデータの書き込みを完全に保証するためには、HDDのプラッタが2回転するのを待つ必要があり、
　一般的な7200rpmのHDDは1分に7200回転＝1秒に120回転なので、1秒につき60回のトランザクションが限界。

ということなので、受信側のSELECTが毎秒1回として、送信側のINSERT頻度次第では可能。

ただし、毎秒60トランザクションは理論値で、実際にはSQLite以外のプロセスもHDDを使うだろうから、
例えば全HDDアクセスの半分を他のプロセスで使うと仮定すると30回/秒まで、もしくはHDDがビジーで
90%を他のプロセスが使う環境であればSQLiteのトランザクションは6回/秒が限界ということになる。
SSDの場合は多分もっと多いけどね。その辺はデバイスの書き込み能力によって計算が必要。

あとはトランザクション内で色々操作したらその分SQLiteからHDDへの書き込み回数も増えるだろうから、
実際のトランザクション数の限界はもうちょい減るかもね。
キューなら不用になった行は受信側で印をつけたり消したりもするだろうし。

**NAME IS NULL** · 2022/08/28(日) 17:15:31.43

>>887
キューなんてOS落ちたら内容保持してても意味ないからそのFAQの最後にある
PRAGMA synchronous=OFF
にすればいいだけ

**NAME IS NULL** · 2022/08/28(日) 17:22:14.27

意味がないかどうかは要件次第でしょ

**NAME IS NULL** · 2022/08/28(日) 22:47:29.13

そりゃすげー特殊な案件まで含めたらそんな案件もあるのかも知れんけどねw

**NAME IS NULL** · 2022/08/29(月) 13:53:59.82

SSDだとどうなのか

**NAME IS NULL** · 2022/09/03(土) 09:19:43.37

プロセス間のキューならOS落ちても起動後に続きから処理したいケースなんて
いくらでもあるから、すげー特殊なんてこたあない。普通にあり得る。

PRAGMA synchronous=OFFってよく分かってないんだけどディスクにsyncしなくても他のプロセスとの
一貫性って保てるのかな？OS介してればディスクにsyncする前でもキャッシュから読まれるからセーフ？
ネットワークファイルシステムだったら駄目っぽいけどローカルで完結するなら良いのかな・・？

**NAME IS NULL** · 2022/09/03(土) 09:41:50.61

>>892
> プロセス間のキューならOS落ちても起動後に続きから処理したいケースなんていくらでもあるから、すげー特殊なんてこたあない。普通にあり得る。
簡単そうに言ってるけどプロセス側もどこまで処理したかをキチンと記録して回復しないといけないしそもそもOS落ちるってことはどこまで記録されてるかの保証もないしヘタしたらファイルシステムぶっ壊れてる可能性すらあるのに普通にあるとか言われても草

> PRAGMA synchronous=OFFってよく分かってないんだけどディスクにsyncしなくても他のプロセスとの
> 一貫性って保てるのかな？OS介してればディスクにsyncする前でもキャッシュから読まれるからセーフ？
簡単に言えばキャッシュの内容をストレージにいちいち反映させない（暇になったら反映する）ってこと
一貫性の管理はメモリー上でやってるから問題ない

> ネットワークファイルシステムだったら駄目っぽいけどローカルで完結するなら良いのかな・・？
ネットワークファイルシステムでも同じだよ、ファイルシステム自体はサーバー側にあるんだし

**NAME IS NULL** · 2022/09/03(土) 16:24:29.73

>>892
あり得るとかじゃなくて極々普通にあるよ
メッセージキュー使ったシステムに少しでも関わったことがあれば誰でも知ってること

**NAME IS NULL** · 2022/09/03(土) 16:36:14.26

>>894
自演乙？w
とりあえず具体的なシステム名頼むわ

**NAME IS NULL** · 2022/09/05(月) 10:23:23.55

Chrome開発チームがSQLiteチームとWebAssembly版SQLiteを開発中。Webブラウザ上からのファイル書き込みで永続化も可能。Web SQL APIの代替として－ Publickey
https://www.publickey1.jp/blog/22/chromesqlitewebassemblysqlitewebweb_sql_api.html

**NAME IS NULL** · 2022/09/07(水) 21:37:10.98

>>893
別の人です。

簡単に出来るとは言ってないけど・・・。当然ジャーナル管理も必要だしファイルシステムのチェックだって必要。
だけどプロセス間のメッセージキューをちゃんと作ろうと思ったら普通に出てくる要件だよ。
特にミドルウェアとかだと必須。OS落ちたらキューの内容を保持していても意味が無い、なんてことは決して無い。
WEB開発とかしかしない人からしたら特殊に見えるのかもしれんけど・・・。

ただ、>>886が仮にそういう要件だったとして、本当にSQLiteで実装するんだとしたら、SQLiteだけでそういうジャーナルとかの管理がどうにかできるのかはよく検討しないといけないだろうね。

**NAME IS NULL** · 2022/09/07(水) 21:48:58.45

>>897
> OS落ちるってことはどこまで記録されてるかの保証もないしヘタしたらファイルシステムぶっ壊れてる可能性すらある
これどうすんの？

**NAME IS NULL** · 2022/09/08(木) 00:12:11.61

>>898
そういうのトランザクション管理の基本だよ

**NAME IS NULL** · 2022/09/08(木) 04:13:22.16

>>899
なんだそれw
どうやるのかを答えられないなら黙ってなよ

**NAME IS NULL** · 2022/09/08(木) 09:33:00.35

>>900
俺は答えられないので、ファイルシステムのジャーナル機能と
SQLiteのトランザクション機能におんぶにだっこだわ

炊飯器の炊飯の仕組みはわからんけど説明書は良く読む派です

**NAME IS NULL** · 2022/09/08(木) 10:10:19.28

>>901
> ファイルシステムのジャーナル機能と
> SQLiteのトランザクション機能におんぶにだっこだわ
それOS落ちた時も確実に動くことが保証されてるの？

**NAME IS NULL** · 2022/09/08(木) 12:10:26.32

>>902
電断に勝つことを最終目標としてんだからまあ大丈夫っしょ

とりあえず電源ガチャガチャを1000回やってOKだったし
原理は知らんけど

**NAME IS NULL** · 2022/09/08(木) 17:08:13.58

>>903
うん、君がイイと思うならいいんじゃね
君のシステムなら

**NAME IS NULL** · 2022/09/08(木) 17:38:42.26

仕事のシステムだけど、ぜんぜんオッケーよ
「リチャードが大丈夫っつったしテストもすげーしたからセーフ」
って仕様書にも書いたよ

**NAME IS NULL** · 2022/09/08(木) 18:02:08.55

>>900
うわー、この人「黙ってなよ」の人だったかw
そりゃキューなんてOS落ちたら内容保持しなくてもOKだわｗｗ
知識も経験も碌に無いのになんで知ったかぶりして出しゃばりたがるんだろうな

**NAME IS NULL** · 2022/09/08(木) 18:49:30.76

>>903
OSクラッシュや電源断の時のトランザクションのatomicityは保証されてるよ
DBがcorruptするのは使い方が間違ってるか設定が間違ってるかSQLiteのバグかOSの欠陥
https://sqlite.org/transactional.html

原理を知りたければ説明書読んでね
https://sqlite.org/atomiccommit.html

**NAME IS NULL** · 2022/09/08(木) 20:33:10.76

>>906
だからそう言うのは>>892に言ってくれよ
OS落ちても続きから処理したいケースがいくらでもあるらしいしw

> プロセス間のキューならOS落ちても起動後に続きから処理したいケースなんて
> いくらでもあるから、すげー特殊なんてこたあない。普通にあり得る。

**NAME IS NULL** · 2022/09/08(木) 20:42:24.40

>>907
リンク先ちゃんと読んでる？
If after power is restored the file is only partially deleted, if some of its data has been altered or erased, or the file has been truncated but not completely removed, then database corruption will likely result.
って書いてますけど？w
そもそも普通のOSは100%ファイルシステムが壊れないと保証してないのにその上に載ってるDBファイルが壊れない保証なんてできるわけないだろ

**NAME IS NULL** · 2022/09/08(木) 22:18:38.75

>>909
うわーそれ何書いてるかわからないんだww
負け惜しみしか言えないなら黙ってなよwww

**NAME IS NULL** · 2022/09/08(木) 22:34:55.79

>>910
> うわーそれ何書いてるかわからないんだww
説明してみ

> 負け惜しみしか言えないなら黙ってなよwww
お前がなw

**NAME IS NULL** · 2022/09/11(日) 23:09:32.22

荒れてるなあ。

OS単体だったらメインフレームでもない限りシステムダウン時のデータ保証はされないのが普通だけど、
それを気にするような要件なら当然ソフト(ファイルシステム・ドライバ・ミドルウェア)も
ハード(HDD/SSD・ストレージ装置・キャッシュ制御)もそれなりのものを入れて
システム全体で保証するだろうから、SQLite観点で仕様を検討する上ではその議論は不毛じゃないかね。
SQLiteを使ってるプロセスとしてデータ保証が出来ていればOKと思う。

データ保証が必要なキューのアーキテクチャの云々はスレ違いなので他スレでどうぞ。

**NAME IS NULL** · 2022/09/12(月) 03:03:35.28

>>912
それトランザクションのAtomicityを保証するという話と違わないか？

**NAME IS NULL** · 2022/09/12(月) 06:19:00.62

>>910
あれ？
説明まだかなーーーw

>>912
> OS単体だったらメインフレームでもない限りシステムダウン時のデータ保証はされないのが普通だけど、
>>892,894によるとされるのが普通らしいのでw

**NAME IS NULL** · 2022/09/12(月) 06:40:52.72

何事も過信は禁物で、各レイヤでのバックアップは不可欠
運用システムのリスク許容度に応じて各自が判断しましょうできるように力を養いましょう

**NAME IS NULL** · 2022/09/12(月) 10:01:21.31

ジャーナリングつきのファイルシステムなら急な電源切断は、保証はされないけど、だいたい壊れないやろ。
それでよければいいだけの話。

**NAME IS NULL** · 2022/09/12(月) 10:50:19.58

>>914
OSによるものではなくファイルシステムによるものでは？
ファイルシステムもOSじゃいって言うのならまあそうだけど

**NAME IS NULL** · 2022/09/12(月) 11:15:59.66

>>917
申し訳ないが主語をちゃんと書いてくれ

**NAME IS NULL** · 2022/09/12(月) 15:35:59.82

>>918
お前もな

**NAME IS NULL** · 2022/09/12(月) 15:53:19.49

さすがに>>918の文章を理解できない人には用はないので無駄に絡んでこないでねw

**NAME IS NULL** · 2022/09/12(月) 20:23:51.04

>>920
ウザ絡みはヤメレ

**NAME IS NULL** · 2022/09/12(月) 20:59:28.24

>>921
>>919 に言ってやれよ

**NAME IS NULL** · 2022/09/12(月) 21:49:29.06

ID表示されないとNG出来なくて不便すぎるわ

**NAME IS NULL** · 2022/09/12(月) 21:57:33.35

『データ保証』みたいな曖昧な言葉を使ってるからダメなんだよ

**NAME IS NULL** · 2022/09/13(火) 09:37:38.51

>>923
専用ブラウザで>>918を透明あぼ～んすれば連鎖あぼ～ん出来るよ

**NAME IS NULL** · 2022/09/14(水) 02:14:04.42

RDBMSをExcelだと思っているやつは多いからな。

**NAME IS NULL** · 2022/09/14(水) 10:36:26.09

まあ世の中の9割5分のデータベースはエクセルで代用できるしな

**NAME IS NULL** · 2022/09/14(水) 15:00:13.95

>>927
代用できるというか、活用できてないだけじゃね？

**NAME IS NULL** · 2022/09/14(水) 15:08:09.03

DBの代用しちゃってるくらいならまだ良い方。
仕様書をエクセルで作る人とか、スクリーンショット送ってと言ったらエクセルに貼り付けて送ってくる人とか、色々いるよ・・・。

**NAME IS NULL** · 2022/09/14(水) 17:05:54.06

スクショはどうするのがいいの？
技術に明るい人だけが閲覧するものならどうにでもなるんだけど
そうじゃない人も見るようなやつ

**NAME IS NULL** · 2022/09/14(水) 18:13:56.52

ペイントでjpegにでもすれば

**NAME IS NULL** · 2022/09/14(水) 18:49:38.06

単なるスクショだけならjpegとかでもいいけど複数のスクショにコメント入れたりしたい場合はExcelでもいいと思うよ

**NAME IS NULL** · 2022/09/15(木) 10:10:26.20

未だにexcelを表計算ソフトかなんかだと思ってる人がいるのな

**NAME IS NULL** · 2022/09/15(木) 14:15:37.34

画像にコメント入れるだけならパワポで良いでしょ。せめてワード。エクセルは無い。

**NAME IS NULL** · 2022/09/15(木) 15:20:46.96

PowerPointもWordもページの制約が大きすぎるからそれに合わない用途の場合にExcelが選ばれる
設計書にスクショを含める場合とかならWord使うしユーザーにUIを説明するような用途ならパワポ使う
特にスクショを多く含むWordは手間書ければキレイに見せられるがメンテコストが高い

そしてここはSQLiteスレ

**NAME IS NULL** · 2022/09/16(金) 20:31:07.99

Excel等のOffice製品に貼り付けた画像は、ExcelファイルのZIP圧縮を展開すれば、Excel内部では画像ファイルとして存在しているので、Excelファイルに貼り付けるのも悪くはない。

画像ファイルで渡してこないことを馬鹿にしているけど、おそらく馬鹿にしているやつもWindowsのスナッピングツールではなく、プリントスクリーンキーで画面キャプチャを取っていそう。

どっちもどっちだろうな。

**NAME IS NULL** · 2022/09/16(金) 21:39:33.85

さらにどうでもいい比較を放り込んでくるいつものキチさんｗ

**NAME IS NULL** · 2022/09/19(月) 15:29:05.92

なんでこんな素人がここにいるのかがわからないよな

**NAME IS NULL** · 2022/10/26(水) 14:05:44.40

22-Year-Old Vulnerability Reported in Widely Used SQLite Database Library
https://thehackernews.com/2022/10/22-year-old-vulnerability-reported-in.html
SQLite Release 3.39.2 On 2022-07-21
https://sqlite.org/releaselog/3_39_2.html

>>この脆弱性は、数十年前には非現実的と見なされていたシナリオ (入力として 1 GB の文字列を割り当てる) が、64 ビットコンピューティングシステムの出現により実現可能になった例でもあります。

**NAME IS NULL** · 2022/10/27(木) 01:09:40.82

へー、興味深い。そういうのは他のソフトとかでもあったりするんだろうな。

**NAME IS NULL** · 2022/10/29(土) 21:05:59.61

2000年まで使われると思わずに西暦の下二桁が99までしか考慮されていなかったのが、まだ25年くらい前の話だしな。

**NAME IS NULL** · 2022/10/29(土) 21:26:11.28

ほんの30年前のHDDには504MBの壁とかあったしな

**NAME IS NULL** · 2022/10/30(日) 01:25:04.75

アドレス空間は64KBなのにメガロムは128KBもあってさ
バンク切り替えの概念は当時の自分には難しすぎてな・・・

**NAME IS NULL** · 2022/10/31(月) 12:17:57.74

SQLiteの正式なWebAssembly版「SQLite3 WASM/JS」が登場－ Publickey
https://www.publickey1.jp/blog/22/sqlitewebassemblysqlite3_wasmjs.html

**NAME IS NULL** · 2022/11/21(月) 11:11:59.56

「SQLite3 WASM/JS」パブリックベータ公開。SQLite 3.40でサポート開始、WebブラウザなどでSQLiteが実行可能に－ Publickey
https://www.publickey1.jp/blog/22/sqlite3_wasmjssqlite_340websqlite.html

>>本バージョンから...(略)...配布される公式のバイナリにLinux版、Windows版、Mac OS X版、Android版などと共に「SQLite3 WASM/JS」が含まれるようになりました。

**NAME IS NULL** · 2023/01/13(金) 08:42:02.75

SQLite3 WASM/JS、Origin Private File Systemを用いてChrome上の高速なローカルDBが機能するとGoogleが明らかに、廃止されたWeb SQLの代替として利用可能－ Publickey
https://www.publickey1.jp/blog/23/sqlite3_wasmjsorigin_private_file_systemchromedbgoogleweb_sql.html

**NAME IS NULL** · 2023/01/17(火) 18:04:50.16

みんなどのくらいのサイズで使ってるの？
一番大きいテーブルで一万件くらい？
スマホアプリにちょっと乗っける程度で使うもんなの？

**NAME IS NULL** · 2023/01/20(金) 08:56:43.16

>>947
100万件くらいの案件だけど問題なく使えてるよ。レコードサイズにもよると思うけど。
あとはアクセス頻度とか、複数プロセスから同時にアクセスするかどうかとか、その辺によるのでは。

**NAME IS NULL** · 2023/01/20(金) 20:57:01.04

>>948
ありがとうございます
正直勇気が湧きました

**NAME IS NULL** · 2023/01/21(土) 16:11:48.55

1億件くらいまでなら余力があると思う

**NAME IS NULL** · 2023/01/21(土) 22:51:28.09

selectだけならなんぼでもいけそうやな
B-Treeの構造上

**NAME IS NULL** · 2023/01/26(木) 03:02:27.75

マシンパワーが上がっているから、処理性能も連動して上がる。

**NAME IS NULL** · 2023/01/26(木) 21:16:21.56

https://www.sqlite.org/np1queryprob.html
> The SQLite database runs in the same process address space as the application.
> Queries do not involve message round-trips, only a function call.

HDD→SSDでクッソ恩恵受けてそう。

**NAME IS NULL** · 2023/02/03(金) 13:26:52.89

デスクトップに a.db て適当な名前のdb作って書き込んでたら
書き込み中に a.nal ってファイルが現れてフイタ

**NAME IS NULL** · 2023/02/14(火) 07:54:16.00

ちんちん！シュッ！シュッ！シュッ！

**NAME IS NULL** · 2023/03/14(火) 20:16:24.68

インサートだけの簡単なプログラムで使ってるけどdbファイルが2GB近くになった
dbファイルを消して新たに同じデータを流し込んだら3MB程度なのに
何でだろう

**NAME IS NULL** · 2023/03/14(火) 23:27:22.57

sqlite3_analyzerで分析してくださいな
https://www.sqlite.org/sqlanalyze.html

**NAME IS NULL** · 2023/03/15(水) 06:44:08.28

そのツールは知りませんでした
分析してみます
ありがとうございます

**NAME IS NULL** · 2023/03/15(水) 18:08:02.02

その2GBをvacuumしたら3MBになるみたいな簡単なオチではないよね・・・？

**NAME IS NULL** · 2023/03/15(水) 19:12:45.18

>>959
そりゃ当然なるやろ
VACUUM相当のことをやったら3MBになったと書いてるじゃん

INSERTだけで3MBが2GBになる理由がわからなければ
アプリで定期的にVACUUMしなければいけないかわからないから
質問者的には意味が無いと思うよ

**NAME IS NULL** · 2023/03/15(水) 21:50:42.97

「インサートだけの簡単なプログラム」←これが一番怪しい気がする。
実はインサートだけじゃなかった、に一票。

**NAME IS NULL** · 2023/04/11(火) 07:27:01.54

SQLiteってトランザクションログとかあるでしょうか
実際の入力値に比べてdbファイルが随分デカくなってる気がするので

**NAME IS NULL** · 2023/04/11(火) 16:57:58.97

dbファイルが大きくなる問題に悩んでいる者ですがTextに長い文字が入ってくると項目の長さも拡張されるでしょうか
SQLServerでのMAXの精度指定のようなイメージです

ちなみにバキュームをしてもdbファイルのサイズは変わらないので知らない処理がこっそりデリートしてる事は無いと思います

**NAME IS NULL** · 2023/04/11(火) 20:01:26.80

隙間にデータを埋めたり、小さい隙間をなくす処理をしていたりと、初心者しか思いつかないようなネタを考えてられるのがすごいな。

あちこちで同じネタを製品別に書くのも飽きないか？

**NAME IS NULL** · 2023/04/11(火) 20:02:59.91

ファイル内の物理的なデータ位置が頻繁に変わる実装じゃ、使い物にならねえよw

**NAME IS NULL** · 2023/04/11(火) 20:44:25.60

ストレージの断片化を進める仕組みにメリットがあるかと考えればわかると思う

狭いところを使おうとして、他のデータを移動させるのもメリットがあるのか

**NAME IS NULL** · 2023/04/11(火) 20:56:22.64

>>963
SQLiteのtext型は、高度なRDBMSのLOB型と同じで、サイズが巨大だから安易に使うとどんどんデータファイルが大きくなる。

text型は巨大な文字データ型。

自分が格納している文字列に対して、使わない長さの領域を確保するので、INSERTでレコードが増えれば、ものすごい勢いでデータファイルが大きくなる。

SQLiteは大量のレコードを扱う用途には向いていない。

**NAME IS NULL** · 2023/04/11(火) 21:04:44.42

一個のファイルですもんねぇ。

**NAME IS NULL** · 2023/04/11(火) 21:18:51.61

>>966
mallocのアルゴリズムみたいなやつでしょ
細かいやつ用とでかいやつ用にわけておくやつ
データの移動はさすがにバキューン以外でやらんよ

**NAME IS NULL** · 2023/04/11(火) 23:28:05.04

まーたいい加減な嘘連投するやつ来てるね
質問者が騙されないことを祈る

**NAME IS NULL** · 2023/04/12(水) 08:36:27.57

SQLite公式マニュアル
https://www.sqlite.org/index.html

text型は文字列型というより、文章・文書の内容を格納する大きな文字データ型

text型を使うとレコードサイズが大きくなるため、レコードが増えるとdbファイル(データファイル)がすぐに大きくなる。

バキュームしてもtext型のカラムが確保している部分が大きいので、さほどdbファイル(データファイル)は小さくならない。

**NAME IS NULL** · 2023/04/12(水) 09:45:02.89

>>971
どこにそんなこと書いてあるのか・・・

**NAME IS NULL** · 2023/04/12(水) 17:29:05.92

いつもの法螺吹き君はカラムがすべて固定長だとでも思ってるみたいだねｗｗ

**NAME IS NULL** · 2023/04/12(水) 17:30:19.05

保存してる文字列のサイズが大きければ保存先のファイルが大きくなるのは当然だよね
圧縮すれば小さくなるけどそれはデータ型とは関係のない話

**NAME IS NULL** · 2023/04/12(水) 20:20:43.81

>>974
そういうのは素人考えだよ？

**NAME IS NULL** · 2023/04/12(水) 20:28:28.28

>>973
固定長じゃなくて、ブロックのような単位で領域を確保する。

あなたのような素人にはファイルのどこにデータがあるのか考えたこともないんだろうね。

バキュームは位置が変わるんだよ。

意味がある文字列が長い文字列に更新されたときに離れたところに続きのデータを配置すると思っているかのような言い草だけど、それこそ古い考え方だよ。

VSAMファイルみたいな階層型データベースの改良版ではないぞ。

**NAME IS NULL** · 2023/04/12(水) 20:29:09.31

>>974
それはまったく違う。dbファイルの中身を比較すればわかるだろ

**NAME IS NULL** · 2023/04/12(水) 22:20:48.62

また関係ない話を持ち出して法螺吹くボラクルｗｗ

>固定長じゃなくて、ブロックのような単位で領域を確保する。
固定長の意味すら知らないんだなｗｗ

>バキュームしてもtext型のカラムが確保している部分が大きいので、さほどdbファイル(データファイル)は小さくならない。
知りもしないことで↑こんな嘘ついてる暇があったら基礎を勉強してねｗ

**NAME IS NULL** · 2023/04/12(水) 22:22:44.06

>>978
https://www.sqlite.org/fileformat2.html

**NAME IS NULL** · 2023/04/16(日) 15:33:14.96

エンジン