SQLite Part.10
レス数が1000を超えています。これ以上書き込みはできません。
ファイル内の物理的なデータ位置が頻繁に変わる実装じゃ、使い物にならねえよw ストレージの断片化を進める仕組みにメリットがあるかと考えればわかると思う
狭いところを使おうとして、他のデータを移動させるのもメリットがあるのか >>963
SQLiteのtext型は、高度なRDBMSのLOB型と同じで、サイズが巨大だから安易に使うとどんどんデータファイルが大きくなる。
text型は巨大な文字データ型。
自分が格納している文字列に対して、使わない長さの領域を確保するので、INSERTでレコードが増えれば、ものすごい勢いでデータファイルが大きくなる。
SQLiteは大量のレコードを扱う用途には向いていない。 >>966
mallocのアルゴリズムみたいなやつでしょ
細かいやつ用とでかいやつ用にわけておくやつ
データの移動はさすがにバキューン以外でやらんよ まーたいい加減な嘘連投するやつ来てるね
質問者が騙されないことを祈る SQLite公式マニュアル
https://www.sqlite.org/index.html
text型は文字列型というより、文章・文書の内容を格納する大きな文字データ型
text型を使うとレコードサイズが大きくなるため、レコードが増えるとdbファイル(データファイル)がすぐに大きくなる。
バキュームしてもtext型のカラムが確保している部分が大きいので、さほどdbファイル(データファイル)は小さくならない。 いつもの法螺吹き君はカラムがすべて固定長だとでも思ってるみたいだねww 保存してる文字列のサイズが大きければ保存先のファイルが大きくなるのは当然だよね
圧縮すれば小さくなるけどそれはデータ型とは関係のない話 >>973
固定長じゃなくて、ブロックのような単位で領域を確保する。
あなたのような素人にはファイルのどこにデータがあるのか考えたこともないんだろうね。
バキュームは位置が変わるんだよ。
意味がある文字列が長い文字列に更新されたときに離れたところに続きのデータを配置すると思っているかのような言い草だけど、それこそ古い考え方だよ。
VSAMファイルみたいな階層型データベースの改良版ではないぞ。 >>974
それはまったく違う。dbファイルの中身を比較すればわかるだろ また関係ない話を持ち出して法螺吹くボラクルww
>固定長じゃなくて、ブロックのような単位で領域を確保する。
固定長の意味すら知らないんだなww
>バキュームしてもtext型のカラムが確保している部分が大きいので、さほどdbファイル(データファイル)は小さくならない。
知りもしないことで↑こんな嘘ついてる暇があったら基礎を勉強してねw このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 3905日 23時間 13分 33秒 レス数が1000を超えています。これ以上書き込みはできません。