私はSQLを初めて使い、マルチプレイヤーゲームのアカウント情報を格納するテーブルを作成しています。私は何が最も効率的な方法は、多くのデータを格納するのだろうかと思います。これらの3つの列のために推奨SQLの種類と長さ
は、私が思うに、私はすでにそれを考え出した：
username: VARCHAR(20)
password: VARBINARY(16) for MD5-Hashes
email: VARCHAR(70)
あなたはこれについてどう思いますか？
これ以外にも、私は実際には予測できないより柔軟なデータ（セーブゲームデータ）がたくさんあります。このデータをTEXT型のフィールドにXMLデータとして保存することは賢明でしょうか？それともPHPを使って保存する方がいいですか？
ありがとうございました。 ロブ
アドバイスのカップル：あなたはfixen長文字列、使用している場合は
あなたの特定のケースに複数の関連注記：
TEXTとBLOBの違いは何ですか？ –
テキストはテキストデータ用です。 BLOBはバイナリデータ用です –
xmlをテキストフィールドに保存しないでください。任意の非構造化データを格納できる別のデータベースエンジンを使用します。 （look up nosql）
Hm。私はプロバイダが私にそのオプションを与えてくれるとは思わない。しかし、私は尋ねるつもりです。 –
ドメイン名も含めると、電子メールアドレスの長さが短すぎることに同意します。最大のGmailの長さに従うことができます。
ゲームデータをファイルとして保存し、パスをデータベースに保存する方がよい場合もあります。テーブルに大きなデータを置くことは、常に悪い考えです。
これは、クラスタ化インデックスが使用され、行の内容がインデックスに格納されているmySQL innoDBストレージエンジンでインデックスを使用する場合に特に当てはまります。インデックスは非常に大きくなり非効率的になります。
はまたVARCHARの場合、特に後者2
電子メールの長さのチップをありがとう。問題は、私が非常に低い応答時間と非常に頻繁にデータの一部にアクセスする必要があることです。だから私はそれをファイルとして保存するのが良いとは思わない。 –
、同様に非常に遅くなるSELECT/INSERT/UPDATEを含む問い合わせ、ほとんどのDBは、文字を加えた長さの必要数を使用しています。一部のデータベースでは、255未満の場合は1バイトの長さが使用されます。したがって、小さい長さを指定すると何も購入されません（*この長さを*適用する場合を除く）。パスワードは長さが変わらないのでバイナリを使うべきです。 – maaartinus
タグ空間効率と併せてXMLを言及することは禁じられています。データを複数のテーブルに構造化してスペースを気にしたくない場合は、[JSON]（http://www.json.org）などの無駄の少ないものを使用する必要があります。 – maaartinus