1

に 16 桁のセキュリティ番号を登録するオラクルの手順を書かなければなりませんregistered_security_numbers。セキュリティ番号の最初の 6 桁は1234 11または1234 12であり、残りの 10 桁はランダムに生成されることがわかっています。

私には2つの可能な解決策があります:

  1. プロパティ を設定して、考えられるすべてのセキュリティ番号を生成し、それらをpossible_security_numbersテーブルに挿入する 2 番目のプロシージャを記述しますfree=1。次に、新しいセキュリティ番号を登録するリクエストを受け取ったら、possible_security_numbersテーブルにクエリを実行してランダムなセキュリティ番号を取得します。これは無料で、に挿入しregistered_security_numbersます。

  2. 暗証番号の登録依頼が来るたびに、 1234 1100 0000 0000 から 1234 1299 9999 9999までの乱数を生成 し、テーブルに存在しない暗証番号を取得して registered_security_numbersに挿入しregistered_security_numbersます。

possible_security_numbers（1）テーブルには数十億のエントリが含まれ、それがどれほど優れているか、または選択/更新をどれだけ速く実行できるかがわからないため、私は好きではないアプローチです。

registered_security_numbers（2）テーブルに多くのレコードがある場合、範囲から乱数を生成することが何度も繰り返される可能性があるため、嫌いなアプローチです。

誰かが他の解決策を持っているかどうか、または私の解決策についてコメントできるかどうかを知りたいのですが、それは私にとって悪いように思えます...</p>

4

1 に答える 1

2

実際に生成する数字はいくつですか？

せいぜい 100 万 (10^6) 個の数値を生成すると想像してください。その場合、2 番目の乱数を生成する必要がある確率は、10^-5 分の 5 (0.00005 または 0.005%) です。その場合、時折 2 番目の数を生成するコストや、3 番目の数を生成することがほぼ不可能であることを心配しても意味がありません。2 番目の方法は、はるかに効率的です。

一方、時間の経過とともに 10 億個の数値を生成するつもりであると想像してください。その場合、最終的に、2 番目の数値を生成する必要がある確率は 5% であり、妥当な頻度で 3 つまたは 4 つの数値を生成する必要があります。ここでは、トレードオフを把握するのがはるかに困難です。ビジネスによっては、一意の制約違反の例外をキャッチし、一部の呼び出しで複数の番号を生成することによるパフォーマンスへの影響により、サービスが頻繁に SLA に違反する可能性がありますが、有効な番号を列挙する方が平均的に効率的である可能性があります。

3 番目に、時間をかけて 200 億の数すべてを生成するつもりだと想像してください。その場合、残りの有効な数値を 1 つ見つける前に、最終的に 100 億の乱数を生成する必要があると予想されます。その場合、可能なすべての数値を列挙し、どの数値が使用されたかを追跡するという最初のオプションを使用すると、明らかな利点が得られます。

于 2013-03-04T22:02:32.760 に答える