ユーザー間のメッセージを記録する MySQL のメッセージ テーブルがあります。典型的な ID とメッセージ タイプ (すべて整数型) とは別に、実際のメッセージ テキストを VARCHAR または TEXT として保存する必要があります。フロントエンドの制限を 3000 文字に設定しています。これは、メッセージがこれより長くデータベースに挿入されないことを意味します。
VARCHAR(3000) または TEXT を使用する理由はありますか? VARCHAR(3000) を書くだけで、やや直感に反する何かがあります。私はスタック オーバーフローに関する他の同様の投稿を見てきましたが、このタイプの一般的なメッセージ ストアに固有のビューを取得するとよいでしょう。
TEXTまた、テーブルが実際のストレージの場所へのポインタを持っているだけで、テーブルから離れて格納されるBLOB 場合があります。保存場所は、データ サイズ、列サイズ、row_format、MySQL のバージョンなど、さまざまな要因によって異なります。
VARCHARテーブルとインラインで格納されます。VARCHARサイズが妥当な場合は高速ですが、どちらが高速になるかはデータとハードウェアによって異なります。データを使用して実際のシナリオをベンチマークする必要があります。
ユーザー入力の長さを予測できますか?
VARCHAR(X)
最大長:可変、最大 65,535 バイト (64KB)大文字と
小文字:ユーザー名、電子メール、国、件名、パスワード
文章
最大長: 65,535 バイト (64KB)
ケース:メッセージ、電子メール、コメント、書式付きテキスト、html、コード、画像、リンク
中文
最大長:
16,777,215バイト(16MB)
ロングテキスト
最大長: 4,294,967,29 バイト (4GB)
ケース:教科書、プログラム、長年のログ ファイル、ハリー ポッターと炎のゴブレット、科学研究ログ
この質問に関する詳細情報があります。
ベストプラクティスを明確にするために：
テキスト形式のメッセージは、ほとんどの場合、TEXT として保存する必要があります (最終的には任意の長さになります)。
文字列属性は VARCHAR として保存する必要があります (送信先のユーザー名、サブジェクトなど)。
フロントエンドの制限があることは理解していますが、それがなくなるまでは素晴らしいことです。(笑) 秘訣は、DB をそれに接続するアプリケーションとは別のものとして考えることです。1 つのアプリケーションがデータに制限を課しているからといって、データが本質的に制限されているわけではありません。
メッセージ自体が 3000 文字を超えないように強制している理由は何ですか? それが単なる任意のアプリケーションの制約 (たとえば、テキスト ボックスなど) である場合はTEXT、データ レイヤーでフィールドを使用します。
免責事項: 私は MySQL の専門家ではありませんが、これは私の理解する問題です。
TEXT は mysql 行の外に格納されていると思いますが、VARCHAR は行の一部として格納されていると思います。mysql 行には最大行長があるため、VARCHAR を使用して、行に格納できるその他のデータの量を制限できます。
また、VARCHAR が行の一部を形成するため、そのフィールドを参照するクエリは、TEXT チャンクを使用するクエリよりもわずかに高速になると思います。