平均して 1 段落のテキストを保存する必要がありますが、これはデータベースに約 800 文字になります。まれに 2000～2500 文字になることもあります。マニュアルを読みましたし、すでにこのような質問がたくさんあることは知っていますが、stackoverflow で 10 件以上の質問を読みましたが、text を単に使用すべきか、varchar(2000) のようなものを使用すべきか、まだ判断が難しいです。半分は varchar を使用すべきと言っているようですが、残りの半分は text を使用すべきと言っているようです。255 文字を超える場合は常に text を使用するべきだと言う人もいます (そうです、これは varchar が最大 65k まで許可された 5.0.3 以降の話です)。しかし、文字数が 255 を超えるたびに text を使用するのであれば、それが常に最善のオプションであるのに、なぜ MySQL はわざわざサイズを増やす必要があるのかと考えました。
どちらもストレージのサイズが可変であると読んだのですが、私の状況では違いはないのでしょうか? 個人的にはvarchar(2000)に傾いていましたが、varcharはデータをインラインで保存しますが、textは保存しないと読みました。これは、この列を常に選択する場合はデータをvarcharとして保存する方が適切で、逆にこの列をめったに選択しない場合はtextを使用する方が適切であることを意味しますか? それが本当であれば、テーブルでクエリを実行するときにこの列を選択することはほとんどないため、text列を選択すると思います。 問題になる場合は、このテーブルも頻繁に結合されます(ただし、列は選択されません)。この場合もtextを使用する利点がさらに高まりますか?
この場合、テキストを使用するべきだという私の仮定は正しいでしょうか?
ベストアンサー1
テーブルに TEXT 列または BLOB 列がある場合、テーブルをメモリに保存することはできません。つまり、すべてのクエリ (キャッシュにヒットしない) はファイル システムにアクセスする必要があり、メモリよりも桁違いに遅くなります。
したがって、この TEXT 列は、実際に必要なときにのみアクセスされる別のテーブルに保存する必要があります。この方法では、元のテーブルをメモリに保存できるため、はるかに高速になります。
データを 1 つの「メモリ テーブル」と 1 つの「ファイル テーブル」に分割すると考えてください。これを行う理由は、必要な場合 (つまり、テキストが必要なときのみ) を除いて、ファイル システムにアクセスしないようにするためです。
テキストを複数のテーブルに保存しても何も得られません。ファイル システムにアクセスする必要があります。
申し訳ありませんが、私が言いたかったのは、たとえばフォーラム スクリプトの場合、投稿テーブルに 20 列の投稿データが格納され、実際の投稿も同じテーブルにテキスト フィールドとして格納されるということです。その投稿列は分離する必要がありますか?
はい。
post というテーブルがあるのに、実際の投稿はそこに保存されていないのは奇妙に思えます。おそらく、「actual_post」という別のテーブルに保存されているのでしょうが、よくわかりません。笑
(posts, post_text) や (post_details, posts) などを試すことができます。
タグ テーブルには、tag_id、tag、description の 3 つのフィールドしかありません。description 列も分離する必要がありますか? 3 つの列を格納するためだけに、タグ テーブルと tags_description テーブルが必要ですか?
説明が TEXT 列であり、説明を必要としないこのテーブルに対してクエリを実行する場合は、それが確かに望ましいでしょう。