答える：テキストは多くのDBMSで非推奨になっているようですので、上限のあるblobまたはvarcharのいずれかを使用することをお勧めします（blobを使用すると、varcharとtextの大きな問題であるエンコーディングの問題は発生しません） 。
また、MySQLフォーラムのこのスレッド で指摘されているように 、ハードドライブはソフトウェアよりも安価であるため、最初にソフトウェアを設計して機能させることをお勧めします。その後、スペースが問題になる場合にのみ、その側面を最適化することをお勧めします。したがって、早い段階で列のサイズを過度に最適化しようとしないでください。最初はサイズを大きく設定することをお勧めします（さらに、これによりセキュリティの問題を回避できます）。
さまざまなコメントについて：ここではSQLの狂信が多すぎます。私はSQLとリレーショナルモデルが大好きですが、落とし穴もあります。
シリアル化されたデータをデータベースにそのまま保存する（JSONまたはXML形式のデータを保存するなど）には、いくつかの利点があります。
- データの形式をより柔軟にすることができます。その場でフィールドを追加および削除したり、その場でフィールドの仕様を変更したりできます...
- オブジェクトモデルとのインピーダンスの不一致が少ない：データをフェッチしてから、プログラムオブジェクトの構造とリレーショナルデータベースの構造の間でデータを処理および変換する必要がある場合と比較して、データをプログラム内と同じように保存してフェッチします。 。
また、他にも多くの利点があるので、ファンボイズムにしないでください。リレーショナルデータベースは優れたツールですが、入手できる他のツールを捨てないでください。ツールが多ければ多いほど良い。
具体的な使用例として、データベースにJSONフィールドを追加して、JSONデータの列（プロパティ）が個別にSELECTされることはなく、適切なレコードの場合にのみ使用されるレコードの追加パラメーターを格納する傾向があります。はすでに選択されています。この場合でも、リレーショナル列を使用してレコードを区別できます。適切なレコードを選択すると、必要に応じて追加のパラメーターを使用できます。
したがって、両方の長所（速度、直列化可能性、構造の柔軟性）を維持し、行を区別するための一意のキーとして機能するいくつかの標準のリレーショナル列を使用してから、シリアル化されたデータが生成されるblob/varchar列を使用することをお勧めします。挿入されます。通常、一意のキーに必要な列は2つまたは3つだけなので、これは大きなオーバーヘッドにはなりません。
また、現在JSONデータ型を持つPostgreSQLと、PostSQLプロジェクト に興味があるかもしれません。 リレーショナル列と同じようにJSONフィールドを直接処理します。