2011-10-20 9 views
2

私はいくつかのテーブルの主キーとして整数を使用するデータベースで作業しています。プライマリキーを推測することを比較的困難にしたいのですが、それらは超タイトである必要はなく、整数を数百に増やすだけでなくてもかまいません。私はこれを既存のデータに既存のスキーマに追加しているので、主キー(integer)のデータ型を変更することは実現不可能です。私が思っているのはIDをどのように生成するのが最適かということです。これまでのところ、私はこれらのオプションを考えることができます:MySQLの推測不可能な整数主キー

  1. UUID()を使用してUUIDを生成し、整数に変換します。
  2. ランダムな整数からなる別のテーブルを保持し、トランザクション内のテーブルからテーブルを選択して削除するプロシージャを使用します。
  3. UNIXのタイムスタンプに加えて、ランダムなn桁の数字を使用します。 CONCAT(UNIX_TIMESTAMP(),SUBSTRING(RAND() FROM 3 FOR 6))

他の提案もあります。

ご提供いただけるご意見をお寄せいただきありがとうございます。

おかげで、 ロス

+1

なぜこのようにする必要がありますか?あなたのアプリケーションは、有効なIDを推測していない人に頼るよりも大きなセキュリティを強化していませんか? –

+1

関連:guidsは、パフォーマンスを最大限にするために部分的にシーケンシャル(SQL 2005+ではnewsequentialid())で、クラスタ化インデックスとデータベースレプリケーションIIRCを使用できるようにすることがよくあります。例えば、 http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids.html – sehe

+1

@MartinSmith:この種の情報漏えいは、プライバシーよりもセキュリティよりも懸念されることが多いです。しかし、漏洩した情報は、戦略的な優位性を得るために使用することができます(例えば、今日販売されているウェブショップの数、ウェブサイトへの苦情の件数など) – sehe

答えて

4

なぜあなたはそれをやっていますか?あなたは、データが物理的に格納される方法を台無しにするでしょう。セカンダリインデックスを使用し、ルックアップのためにURLを渡す必要がある場合はGUIDにします。

+2

+1プライマリキーは、自動インクリメントにする必要があります。unsigned int - 「見積もりが難しく、URLに2番目の列が表示されます。 – Konerak

関連する問題