一般的な質問がありました。
次のようなページが生成される URL が非常に気に入っています。
www.example.com/order/1e4fk678
1e4fk678 は、出力を生成する php ファイルにポストされる変数です。
私の質問は次のとおりです。データベース テーブルを作成する最良の方法は何でしょうか。主キーの自動挿入を持つ ID は、1、2、3、... のような ID を生成するだけです。
では、高速なデータベース追跡/トレースをもたらす一意の ID を使用する最良の方法は何ですか?
ありがとう
DBMS は、一意の (auto_increment) 識別子を既に生成しています。あなたが質問で言っていないのは、URL に表示される値を予測不可能にするかどうかです。
そうでない場合は、生成された ID に対して単純に基本変換を行うことができます。
値を予測不可能にする必要がある場合は、文字列としてパディングし (ほとんどの暗号化アルゴリズムはブロック サイズの倍数までこれを自動的に行います)、可逆暗号化を使用して自動インクリメント整数をエンコードし、検証を追加します。ブルートフォース攻撃を検出します。この方法は可逆的である必要はありませんが、暗号化を不可逆にするほとんどの方法 (ハッシュを生成する、データを暗号化キーとして使用する、ランダムな暗号化キーを使用する) には衝突のリスクがあり、暗号化されたデータを暗号化する必要があります。はるかに大きいです。
参照がリモートで提供される場合は、データに一意のインデックスを追加するだけです。しかし、衝突にどう対処するかを考える必要があります。
ランダムな値を使用すると、データ量が少ない場合にメリットがあります。生成時に衝突を検出できますが、生成された値が衝突しないことを確認するコストは、少なくとも O(logN) の割合で増加します (インデックス付きフィールドの場合)。 .
アップデート
[integer の代わりに varchar] を主キーとして使用しても、データベースが遅くなることはありませんか?
いいえ - そしてそれはあなたの心配の最小です.
実際にはunique、mysql で制約付きの文字列列を使用することも、主キー列として使用することもできます。言うだけ：
`id` varchar(..) PRIMARY KEY
テーブル定義で。
この質問を見てください。主キーとしての文字列とそのパフォーマンスの問題を扱っています: MySQL - 文字列を主キーとして使用