-1

アプリケーションのユーザーは Facebook 経由で認証できるため、Facebook の uid をデータベースに保存し、ユーザーがログインしたときに、次のようにデータベースにクエリを実行する必要があります。

SELECT * FROM users WHERE uid = _SOME_UID_;

現在uid、列は VARCHAR ですが、数値型の BIGINT に変換する必要があると思います。

これを行う必要があると思う理由：

  1. プロセッサ時間:一般に、数値を使用した操作 (フィルタリング/インデックス作成) は、文字列を使用した同じ操作よりも常に高速です。

  2. ストレージ:数値が対応する文字列より小さい

  3. うーん... oauth-argument Facebook 認証は、私が使用する唯一の認証タイプです (実際には、これはキャンバス アプリケーションです)。したがって、数値以外の UID を気にする必要はありません。

質問は次のとおりです。

  1. 私は正しいですか？
  2. Facebook はいつの日か非数値の uid を使い始めることができますか?
4

2 に答える 2

1

私は VARCHAR に固執します。

確かに 1 つとして保存できますが、私の意見では、Facebook UID は実際には数字ではありません。これはたまたますべてが数字である文字の集まりですが、これは識別子であり、操作される数字ではありません。

パフォーマンスの違いは実際にはどうなるのだろうか。それがわかると、決断がしやすくなります。

于 2013-03-29T19:03:39.967 に答える
1

それはいくつかの要因に依存します。何よりもまず、何千もの UID または何百万もの UID について話している場合、データ コレクションはどのくらい大きくなる可能性がありますか? プロジェクトが最小のコンテナー (大きな整数) を見つけようとしている場合にスケールについて心配していない場合は、変更に合わせてスケーリングできるかどうかについてはるかに心配しています。

したがって、任意の形式の UID を取り、満足できる適切なサイズの VarChar を選択する必要があります。これには、サニタイズが容易ですが、先頭のゼロや文字には不向きな先行ゼロと bigInt が含まれます。

UID が常に先行ゼロまたはゼロで埋められた数値であることがわかっている場合は、型へのキャストによってサニタイズすることで、セキュリティをわずかに向上させることができます。それとサイズは、bigInt のすべての利点です。

VarChar にはサイズの問題があります。開始する前に最大の UID の長さを知る必要がありますが、先行ゼロ、文字、およびその他の予期しないコンテンツは、現在文字列を消去しているという小さな例外を除いて処理できます。

プログラミングの観点からは、UID は一意のラベルにすぎないため、問題はほとんどありません。インデックスがあれば、少なくとも MySQL が使用している一般的なエンジンでは速度に違いがあるとは想像できません。

したがって、ベストとは、データから最も必要なものを単純に組み合わせたものです。

于 2013-03-30T00:08:45.387 に答える