2017-02-02 14 views
0

クライアントIDの番号が連続しているにもかかわらず、順次戦略を追加するため、競合他社よりも優れた顧客ID番号付け戦略を探しています。だから彼らは場所に関連していないUCIDを持っているかもしれませんが、ソフトウェア会社にのみユニークです。理論的に私がソフトウェアを使用して1000の場所を持っていて、各クライアントに2万の顧客がいる場合は、顧客ID番号が数百万になることは明らかです。異なる顧客のDBで同じ顧客ID命名を使用する

私の思想は、SSNと同様のアプローチを取っています。これは、50の州すべてでSaaSを使用しているクライアントがいるためです。私はクライアントがいる状態が米国に入国したときの回数を使ってプレフィックス・アプローチをとったがっていました。したがって、デラウェアの場合、プレフィックスは01-XXXXになります。これがデラウェア州の37のクライアントであれば、IDは01-0037になり、このクライアントレベルのDBテーブルに入力された最初の顧客は自動的に1から始まります。

このアイデアの賛否はどうなり、何が問題になるのでしょうか。

答えて

0

単一のデータベースサーバーがある場合は、任意のスキームを作成することができます。

番号生成を多くのサーバーに分散すると、UUID(連続していない)や2部構成のメカニズム(2番目の部)。

州ごとに1つのシーケンスがある場合、カリフォルニア州はおそらく最小状態の100倍の数を持つことに注意してください。これは問題ですか?

なぜ、の場合は、「シーケンシャル」ナンバリング戦略が必要なのでしょうか。

番号に穴がある場合はどうしますか?このようなことは、サーバークラッシュなどが発生した場合や、「クライアント」が消滅した場合(死亡、退社、状態外など)に発生します。

連続番号は請求書に役立ちます。監査では、不足している請求書や追加の請求書がないことを「証明」することができます。クライアントIDの理由

関連する問題