顧客番号、注文番号の最適な形式は何ですか？
大規模な国際企業は、新しいWebおよびMOTO（メール注文および電話注文）処理システムを展開しています。特に、注文番号と顧客識別番号の両方の形式を設計する必要があります。
あなたの意見で最高のフォーマットは何ですか？前提条件と考慮事項をリストしてください。
受け入れられた回答
マイケル・ハレンの回答は、投票数が多いため選択されましたが、マイケルの回答をより完全にするために、他の回答やコメントを読んでください。
すべての数字またはすべての文字で移動します。混合する必要がある場合は、あいまいな文字（Il1m、O0など）がないことを確認してください。
表示/印刷するときは、3〜4文字ごとにスペースを入れますが、システムがスペースなしで入力を処理できることを確認してください。
編集：考慮すべきもう1つのことは、注文、顧客などを区別するための組み込みの方法があることです。顧客は常に10で始まり、注文は常に20で始まり、ベンダーは常に30で始まります。
DO N'Tエンコード[〜＃〜] any [〜＃〜]可変の顧客/注文情報を数字に！そして、あなたはすべてが可変です！
上記の提案の中には、地域コードが含まれています。企業は動くことができます。あなた自身の会社は、地域の独自の定義を再編成して変更するかもしれません。顧客/会社名も変更できます。
顧客/注文情報は顧客/注文レコードに属します。IDではありません。顧客/注文レコードは後で変更できます。 IDは一般に石で書かれています。
数値が生成された日付をIDにエンコードするだけでも安全に思えるかもしれませんが、数値を生成するシステムで日付が間違っていないことを前提としています。繰り返しますが、これはレコードに属します。それ以外の場合は修正できません。
複数のシステムがこれらの数値を生成しますか？その場合、日付ベースの番号や連続番号のみを使用すると、重複する可能性があります。
会社についてあまり知らなくても、このパスから始めます：
- 数字のタイプを識別する1文字のコード。 [〜＃〜] c [〜＃〜]顧客の場合、[〜＃〜] r [〜＃〜]注文の場合（「O」をゼロと混同される可能性があります）など。
- 番号を生成したシステムの識別子。この識別子の長さは、これらのシステムがいくつあるかに依存します。
- 生成するシステムに固有のシーケンス番号。ただのカウンター。
- 推測可能な注文/顧客番号を防ぐための乱数。あなたの妄想が必要とする限り、これを作ります。
- 簡単なチェックサム。セキュリティのためではなく、エラーチェックのためです。
これをセグメントに分割すると、他の人が指摘しているように人間が読みやすくなります。
CX5-0000758-82314-12は、このアプローチで生成される可能な数です。これは以下で構成されます：
- C：顧客番号です。
- X5：番号を生成したステーション。
- 0000758：これは、X5によって生成された758番目の番号です。このステーションIDまたはステーション自体を廃止する前に、1000万を生成できます。または、ゼロでパディングしないでください。制限はありません。
- 82314：これはランダムに生成され、顧客IDを推測する確率は1/100,000になります。
- 12：チェックサム。
数字のみを使用する主な利点は、10キーを使用してより効率的に数字を入力できることです。
その数の長さは、できるだけ余裕を持ってカタログ化する予定のエンティティ空間全体を網羅しながら、できるだけ短くする必要があります。これには注意が必要な場合があり、少し考えてください。少し 集合論 は、要素のグループが与えられると、アクセスできるユニークキーの数を与えることができます。
話すときは、数字を2〜4桁のセットに分割するのが自然です。ダッシュを何らかのパターンで挿入することにより、より効率的で明確な方法で顧客に「強制」を繰り返すことができます。
たとえば、323-23-5344は、もちろん、社会保障番号の形式であり、番号を発声するときに一時停止する場所をスピーカーに通知するのに役立ちます。また、数字を書くときの視覚的な描写を提供し、数字をコピーするときの比較を容易にします。
次に、ダッシュを入力する必要がないように、順序付けシステムが入力を正しくマスクすることをお勧めします。これを印刷フォームに引き継いで、何を入力すべきかを明確に予測する必要があります。たとえば、印刷されたダッシュで区切られた各桁の印刷されたボックス。
特にこれらの属性が変更される可能性がある場合、この数値に多くの情報を埋め込む必要があることに同意しません。たとえば、「323」に「素敵な顧客です」という意味を付けたとしても、彼らは態度で4回電話します。次に、顧客のキーを「324」、「ガタガタです」に変更しますか？地域04にいて、会社を地域05に移動するとどうなりますか？
その場合、オプションはデータベース全体でその主キーを更新するか、そのキーに埋め込まれた情報の信頼性が失われるという曖昧さを持ち、疑わしいユーティリティのキーに埋め込まれたすべての情報をレンダリングすることです。
データベース内の個別のフィールドとして変更される可能性のある属性を保存し、顧客番号をその顧客の一意の不変のキーにすることが望ましいです。
ダニエルとマイケルの質問に基づいて：分離された数字が何か他のものを意味する場合はさらに良いです。たとえば、アカウント番号が次のような会社で働いていました。
xxxx-xxxx-xxxxxxxx
最初の数値セットは地域を表し、2番目のセットはその地域内の市場を表しました。数値が何であるかを知ることに慣れると、顧客のアカウントを見なくても、アカウントがどのエリアにあるかを簡単に知ることができました。
この質問に答えるとき、いくつかの仮定があります。大規模な国際組織であるという事実に基づいているものもあれば、2つの異なるテーブルタイプ用の形式であるという事実に基づいているものもあります。
国際組織であるという事実に基づく仮定：
- 各地域が独立して動作する必要がある可能性が高いです。つまり、地域Aは地域Bとは別に顧客番号を追加できる必要があります。
- 各地域ではおそらく異なる言語が使用されるため、世界中のユーザーが識別子を簡単に入力できるようにするには、数字とスペースのみを使用することをお勧めします。
この形式が使用される2つのテーブルがあるという事実に基づく仮定：
- この形式は、リストされている2つ以上のテーブルで使用される可能性があるため、任意の数のテーブルを処理できる必要があります。
- 経験豊富なユーザーは、識別子自体にエンコードされた情報に基づいて、どのタイプの識別子を見ているかを知ることができるはずです。
- 識別子がシステム全体でグローバルに一意であれば、それは素晴らしいことです。
考慮事項：
- グローバル企業の場合、数値のみを使用すると識別子は非常に長くなる可能性があります。可能な限り、識別子にエンコードされる外部情報の量を制限する必要があります。
- 識別子は限られた範囲で自己検証可能でなければなりません。つまり、プログラムは何も調べることなく、無効な識別子の大部分を検出できるはずです。これはチェックサムを意味します。
提案された形式： SSSS0RR0TTC
提案された形式は可能な限り単純ですが、単純ではありません。
- [〜＃〜] c [〜＃〜]最初の（右端の）文字は、識別子内の他のすべての文字のチェックサムになります。簡単なチェックサムで十分です。これにより、すべての入力エラーの90％が排除されます。これで十分でないと判断された場合、これを2桁に拡張して、すべての入力エラーの99％を排除できます。
- [〜＃〜] tt [〜＃〜]次のN桁はテーブルタイプ番号を表します。テーブルタイプ番号に数字のゼロを含めることはできません。
- 次の数字はゼロです。このゼロは、テーブルタイプ番号をリージョン番号から分離します。
- [〜＃〜] rr [〜＃〜]次のN桁は地域番号です。地域番号にゼロを含めることはできません。
- 次の数字はゼロです。このゼロは、領域をシーケンス番号から分離します。
- [〜＃〜] ssss [〜＃〜]次のN桁はシーケンス番号です。この数にはゼロを含めることができます。
- 4つの数値の各セットは、慣例により印刷または入力するときにスペースで区切られます。内部的には分離されていませんが、これによりユーザーはそれらを正しく転送できます。
例
想定：
- 顧客テーブルタイプ= 1
- 注文テーブルテーブルタイプ= 2
- US-Alabama = 1の地域コード
- CA-Alberta = 43の地域コード
- Ethopia = 924の地域コード
- 10 1013-アラバマ州の顧客＃1（3はチェックサム：1 +1 + 1）
- 10 1024-アラバマ州の注文＃1
- 9259 0304 3016-カナダ、アルバータ州の顧客＃925903
- 20 3043 4092 4023-エトピアの注文番号2030434
このアプローチの利点：
- 入力ミスした数字の90％がキャッチされます
- テーブルタイプの数に制限はありません
- 地域の数に制限はありません
- 各テーブルには連続した番号が無制限にあります
- 識別子番号は、システムに対してグローバルに一意です。これは重要です。顧客番号を注文番号と間違えたり、その逆を行うことはできません。
- 各領域は、グローバルキーなしでシーケンス番号を独立して追加できます。
欠点
- 各識別子は少なくとも6文字です
- テーブルタイプ番号とリージョン番号は、シーケンス番号をテーブル番号とリージョン番号から分離するために使用されるため、ゼロを含めることはできません。
never IDでユーザー情報を使用します。顧客の姓の最初の文字の後に数字を使用するとします。 Thomsomは顧客THOM-0001である可能性があります。ただ、あなたは間違いを犯したようで、その男の名前はトムソンではなくトムソンです。ユーザーデータを修正できます。IDを変更することはできません。次回トムズの下でトムソンを調べると... ...あなたは彼を見つけることができません。顧客タイプなど、他のデータと同じです。 IDは常に変更できますが、変更することはできません。
これはRDBMSの基本です。
単純にカウント数を使用します。読みやすくするために、連続する4桁を超えないように区切り文字を挿入することをお勧めします。9999-9999は999-99999よりも優れています。また、必要以上に長くしないでください。人々は、単に数字に減るよりも20桁の数字に減るのがずっとイライラします。
ただし、キャッチがあります。特に中小企業の場合、単純なカウンターはあなたが感謝するよりも多くを与えることができます。あなたから何かを注文するとします。注文番号は090145です。来月再び注文し、注文番号は090171です。Er..月に26注文ですか？同じように、私は10年前から活動しているビジネスで顧客0006になるのは気が進まないでしょう。
解決策は簡単です。番号をスキップします。乱数を順番に並べる必要があるため、乱数は使用しないでください。
必要に応じて番号を作成しますが、それ以上ではありません。私は水道代を支払うたびに、20桁の顧客番号と18桁の請求書番号を入力する必要があります。ありがたいことに、私の顧客番号にダッシュを付けると、2つの部分に分けられます。
先行ゼロに依存しないでください。請求書番号にゼロがいくつ含まれているかを把握するのは非常に面倒です。 000000000051415432を例にとります。彼らのシステムは51415432だけを認識しません。
数字をグループ化する。絶対に長い数字を使用する必要がある場合は、4桁のチャンクで十分です。
注文番号は次の形式に従ってください。
ddmmyyyy-####-####
####-####は、毎日の始めにゼロにリセットされます。これにより、注文と発注日を非常に簡単に関連付けることができます。
顧客IDについては、大文字と数字を混ぜますが、Michaelが言ったように、よく間違える文字（0、o、L、1,5、s）を避けます。これにより、30文字が処理されます。 20文字を使用すると、ほぼ64ビットの範囲の顧客IDが得られます。これはセキュリティに非常に適しています。 IDを生成するときは、安全な乱数ジェネレーターを使用してください。フォーマットの表示方法については、次のようにする必要があります。
####-####-####-####-####
マイケルが再び言ったように、システムがダッシュ、スペース、スペースなし、またはダッシュなしを処理できることを確認してください。 （検証前に、入力からこれらの文字をすべて削除する必要があります。）
それがお役に立てば幸いです！
特定のIDの正確さを（強化）するために、小さなチェックサムを（たとえばXORを使用して）追加できます。メールによる場合は、 z-base-32 encodingただし、ここでは、電話による注文では、10進数の識別を好む場合があります。
私が作業している参照 "数字"の一部に先行ゼロを使用していますが、過去7年間にExcelがそれらをテキストとして扱うことを余儀なくされた無駄な時間はわかりません。しないでください。
自動インクリメント整数はすべてコンピューターに適していますが、エラーを発見する人間の能力を大幅に低下させます。それがどれほど重要かは、あなたのビジネス次第です。プロパティ（住宅）に関連するデータを操作し、プライマリリファレンスにはフロントドアが埋め込まれています。エレガントではありませんが、経験豊富な管理スタッフは、データベースに近づく前にマイナーエラー（請求書などを受け取ったとき）の90％を見つけることができます。しかし、この種のプロセスに依存していない環境では、この議論はそれほど説得力がありません。
（今では、参照に意味のあるデータを変更する可能性があるため、参照に意味のあるデータを使用することを強く警告している人もいますが、その中には真実があります。特定のアカウントを最初に開設した地域を表すキャラクターのような過去のイベントに自分自身を固定することができます。そうしなくても、顧客とのコミュニケーションを支援する何らかのパターンがあります。そして、人々は必死に自分のアカウント/注文/顧客番号を見つけようとするため、出生証明書以降のすべての文書を電話で訪れることがあります。とても便利な）
言われていますが、非常に長い参照を作成しないでください。私たちは忙しいので、電話システムでこのがらくたをキー入力し、再起動するためだけに17桁目でミスをする時間はありません。一部の顧客には障害があり、その数は55歳以上になる可能性があります。もう一度、ゼロに注意してください。 14桁の注文番号などが表示されます。彼らは何件の注文を出すと思いますか？
ネットワーク外にデータが集約される場合（したがって、データベースに接続されない場合）-パートナー/サプライヤーが間違いを犯していないことを確認できる、ある種のチェックディジット/正規表現パターンを用意します。これの一例は、英国の電力供給番号システム（MPAN）がその良い例です-人々が自分の記録を維持するために設計されています。タイプミス。
注文/顧客の作成が集中化されていない、または常に集中化されるとは限らないと仮定して、GUIDを使用します
注文/顧客の作成が常に集中化される場合、符号なし整数で十分です。
顧客番号の注文番号がなんらかの「意味」をもつ説得力のある理由はありません。また、発明されたセグメント化された番号スキームは、今後改善される必要があります。ユニークで無意味なものにこだわる。
編集：MOTOの場合、複数文字のアルファベット識別子は電話で問題を引き起こすため、GUIDはすぐに使用できます。複数の分散MOTOロケーションを想定して、各MOTOロケーションにプレフィックス（A、B、Cなど、または01、02、...）を割り当て、顧客IDと注文IDに整数またはビッグ整数を使用します。 01-1は、MOTOロケーション＃1からの最初の注文です。ゼロパディングは不要であり、数字に暗黙の桁制限が課せられ、数字を話すときに顧客が6つのゼロと7つのゼロを区別する必要があることに注意してください。埋め込み固定長形式を使用する必要がある場合は、それぞれ4桁または5桁以下のグループに番号を分割します。
補遺：注文番号と顧客番号は、それぞれのテーブルの主キーである必要はなく、ルックアップ用の一意のインデックス列のみです。おそらく、データベース内の主キーにもっと簡単な/より効率的なものを使用したいと思うでしょう。
数字にこだわる（文字や特別なものは不可）：
- IVRフローに簡単に入力できます
- その国際-言語の面倒はありません
- 文字と数字の混同なし-O対0、I対1
- 先頭の0が無意味である限り、それらをより効果的に保存/操作できます
それは国際的な会社だからです。 4〜6の数字ごとにスペースまたはダッシュを使用して区切ります。また、迅速な識別のためにフォーマットを個別に保持します
例：
000-00000-00000-顧客番号である可能性があります
00000-00000-00000-00000-注文番号にすることができます
16桁の識別子を使用することをお勧めします。印刷または顧客に表示する場合は、xxxx-xxxx-xxxx-xxxxの形式でフォーマットされますが、ダッシュなしの数字としてシステムに保存されます。
この形式を使用する理由は、すでに言ったことを覚えようとするのではなく、電話で数字を読み上げている人が4回に分けて読みやすくなるためです。
必要に応じて、最初の4桁を使用して番号の種類を識別できます。顧客は1000、サプライヤーは2000、注文は3000、請求書は4000などです。
2番目のセットは、yymmの形式を使用して番号自体にエンコードされた情報の種類を保持したい場合、年/月識別子によって、1000-0903-xxxx-xxxxが2009年3月に入力された顧客になります。
これにより、実際のデータ自体に8桁の数字が残ります。
識別子の文字の使用は、アクセントや理解の違いが非常に多様であるため、電話を扱うシステムにとって非常に悪い考えであると考えます。アクセントを正しく理解できません。
注文番号と顧客番号の両方に完全に数値のシステムを使用します。これにより、他の言語の問題を回避できます。
データの入力と検証で問題が発生する可能性があるため、先行ゼロは避けてください。
それぞれの桁数は、予想されるボリュームによって異なります。常に顧客番号よりも多くの注文番号があります。 100000から始まる6桁の顧客番号でも、899,999人の顧客が得られます。注文番号に3〜4桁の数字を追加すると、顧客ごとに999〜9,999の注文が得られます（顧客が1人の場合はさらに多くなります）。
番号付けシーケンスに何らかの種類の識別情報を組み込む必要はありません。顧客がどこから来たかなどを特定するために、他のデータベースフィールドがあります。システムを過度に複雑にしないでください。
KISS（単純なスタックオーバーフローを維持）
形式の問題に関する追加の考慮事項-コードで、OrderIdとCustomerIdに個別のクラスを作成します。これらのクラスは不変であり、入力を検証して、受け入れ可能なIDであることを確認します。また、値は注文IDと顧客IDにはなりません。
最も単純なアプローチは、OrderIdのバッキング値を1で始まるintにし、CustomerIdsを2で始まるintにするか、類似したものにすることです。
私は常に自動インクリメント番号に固執し、シーケンスの桁数がすべて一定になるようにシーケンスを常にシードします-混乱が少ないようです。
また、注文番号、たとえば6桁、200,000で始まり、5桁、10,000で始まる顧客番号を開始することもあります。これにより、たとえば90,000の一意の顧客番号と800,000の一意の注文番号を使用できます。顧客番号か注文番号かを調べます。 （つまり、顧客担当者が電話で電話番号を尋ねた場合、どちらがすぐに明らかになるでしょう）
ただし、それに依存するロジックをアプリに構築することはないため、たとえロールオーバーしても、システムは気にしません。
私にとっては、日付と今日の取引のカウンターの組み合わせを取得することをお勧めします。 5桁の注文番号だけを考え出すことに挑戦しました。それで、私は以下を思いつきます：
- それから現在の日付を取得する必要があります
- 今日のトランザクションの現在のカウンターを取得し、1を追加します。
Decimal（10）よりも大きいカウントを使用することにしたので、カウントにはベース16を使用します。そのため、1,048,575カウントになる16進数（FFFFF）から最大5桁を取得する場合。日付を含めることにより、1日あたり1,048,575カウントを取得できると言えます。そのため、カウントを毎日一意にするために、次の合計を取得して日付を混合しました。
- 実装の年から始まる現在の年数1
- 現在の時間（最大24）
- 年の現在の日（最大365）
そのため、カウントには最大3文字を使用します。したがって、XXX + Todays現在のトランザクションになります。例：
現在の日付：2014-12-31 01:22 PM実装日：2010今日のトランザクションの合計：100
カウント：（5 + 13 + 365）+ 101 = 383101注文番号：AD-5D87D
[〜＃〜] ad [〜＃〜]カスタム注文番号のプレフィックスのみがあります。そのため、私は、実装日から1000000年後の注文番号になります。
とにかく、1日あたりのトランザクションが1000000カウントと高くなる可能性があると考える場合、これは良いソリューションではありません。
うわー-なんてシンプルでありながら明らかになる質問でしょう！そして、多くの矛盾した答え。ここには3つの明らかな候補の答えがあると思います。
1）自動インクリメント長整数を使用します。 2）GUID 3）を使用します。3）IDに他の情報を含む複合タイプを使用します。
より単純なシステム、特にすべてのユーザーが中央データベースにアクセスするWebベースのシステムの場合、（1）はうまく機能します。数字はできる限り短くシンプルに保たれるという利点がありますが、短くはなりませんが、アルファベット文字を避けることができます（同じ文字の名前が異なる国にあることに驚かれることでしょう-ある国Eは別の国Iです）。注文IDと顧客IDを本質的に区別するわけではありませんが、それぞれに「C」または「O」を常に追加または追加して、入力時にそれらを静かにドロップできますか？また、チェックサムまたはエラーチェックもありません。
多くのソフトウェアコンポーネントがその場で番号を作成する必要がある分散システムの場合、マスターデータベースを参照せずに（2）が唯一の方法です。アドレス空間は非常に大きいので、大部分はエラーチェックであるという利点がありますが、同じトークンでは、電話で快適に読むには長すぎて英数字が長すぎます。
（3）に関しては-地域情報または今日の日付を数字に埋め込む-これらは、経験豊富な開発者が訓練するアイデアの一種です。最初は良いアイデアのように見えますが、常にあなたを悩ませるために戻ってきます。顧客が新しい状態に移行した場合、または最初に発行されてから1週間後に注文のキーが手動で変更された場合を考えますか？これらの情報項目は関連するテーブルに属し、エンティティIDのみを表すIDから独立して編集できます。繰り返すには：IDでビジネスデータをエンコードしないでくださいORプライマリキー-実行するたびに、他の人が1日クリーンアップするために時限爆弾を残します。
これが集中型（電話ベース）のシステムであることを考えると、変更が明らかに必要になるまで、オプション（1）を使用します。通常は、シンプルな方が優れています。他の人が提案するようにハイフンを挿入し、必要に応じてチェックサムや識別文字を追加または後置します。
ここでの最大の問題は、問題を考え直さないようにすることです。
私は電子商取引システムの経験が豊富ですが、この投稿で述べたポイントのいくつかは、通信販売システムや電話注文システムにも適用できると思います。
注文の場合、自動インクリメント整数は、データベースの主キーとしてだけでなく、顧客が請求書に表示する番号として完全に機能します。数値に複雑すぎるアルゴリズムを作成する理由はまったくありません。どの国/地域の出身かを知りたい場合は、データベースの別のフィールドを使用します。また、競合他社があなたをスパイすることを心配している場合;聞かせて！あなたが十分な収入を生み出していないためにあなたのビジネスがあなたの競争相手をスパイすることを中心に展開しているなら、おそらくあなたのビジネス観念はそもそも良くないでしょう。また、競合他社をだます場合は、偽の注文を自動作成する独自のスクリプトを作成できます。電子商取引システムが適切に設計されている場合、これは問題になりません。
自動インクリメント整数を使用するキースタッフ：
- すべての数字/数字=>コミュニケーションが簡単で、電話でのあいまいさはありません。数値システムとして0-9を使用するすべての言語/文化で動作します。
- 余分なコーディングはありません
- 請求書では見栄えがよく、顧客が電話で説明するのに必要な最短の桁数です
- 小規模および大企業向け
- スケーラブルです
- Serviceminded/Customerminded（顧客に最適なもの）（箇条書き1および3）
- シンプル
設計しているものは何でも、常に顧客にとって最適なものから始めるべきです。結局のところ、彼らはあなたのテーブルの上に食べ物を置いている人たちです。幸せな顧客は、返品する顧客です。
最初のステップ：このようなシステムを必要とするのに十分な規模の組織には、交換する既存のシステムがあります。可能であれば、以前のシステムのスキームを続行します。古いシステムのデータに基本レベルでさえアクセスできれば、多くのことが簡単になります。
そうは言っても、特にレガシーシステムからのものである場合は、多くの場合、スキームを変更する正当な理由があります。しかし、先に進む前に古いスキームを正式に除外することがしばしば役立つことがわかります。
2番目のステップ：このようなシステムは、真空には決して存在しません。会計、在庫管理、CRMシステムなど、ユーザーIDまたは注文ID、あるいはその両方の組織規模のスキームは既にありますか？もしそうなら、相互運用性をより簡単にするために既存のスキームを採用することを検討してください。多くの大規模な組織には、単一の顧客または注文を指定する複数の方法があり、データから有用なインテリジェンスを取得することがはるかに難しくなります。
番目のステップ：古いシステムのスキームがあまりにもひどすぎて続行できず、他に採用するスキームがない場合は、独自にロールします。この場合、元のスキームの欠点を調べて、それを修正します。正しい答えは、アプリケーションの特定の要件によって異なります。あなたが私たちに与えた問題文は、最終的なフォームがどのように見えるかについて有用に推測するには曖昧すぎます。