1

私のWebアプリケーション（POS）は、複数の支店での販売を処理します。各セールには一意の整数IDがあります。ブランチ1の一部の販売IDはnであり、ブランチ2の次の販売はn +1です。

支店がインターネット接続を失うと、販売情報をブラウザの内部データベースに保存します。ここで、販売IDは最後の販売IDに1を加えたものです。接続が復元されたら、その情報をサーバーに送信してから、実際のデータベースに保存します。

悪夢は、2つ以上のブランチがインターネット接続を失うときに発生します。彼らがオフラインで販売を行い、インターネットが再開すると、サーバーは同じIDで2つの販売を受け取ることになります。これは、顧客のチケットがすでに印刷されているため、恐ろしいことです。

今のところ、各販売IDを、支店IDとその支店の実際の販売番号から組み合わせて作成する予定です。したがって、ブランチ1の販売IDは1-1になり、ブランチ2からの次の販売は2-1になります。ブランチに2つのPOSができるまでは良さそうですが、そうではありませんが、将来性はあまりありません。

最善のアプローチは何だと思いますか？これを行うためのより良い方法はありますか？

4

3 に答える 3

1

理想的には、各POSには独自のIDがあります。たとえば、私は以前、世界中に数千の支店があり、各支店に最大15の販売拠点がある国際的な小売チェーン（ここでは名前を付けません）で働いていました。各POSには独自のIDが割り当てられており、バックエンドシステムへの認証時にこのIDを使用していました。

これがセットアップの場合である場合は、ブランチIDの代わりにPOSIDを使用する必要があります。このように、同じブランチに複数のPOSがある場合は、POSIDをトランザクションIDの前に付加します。

于 2011-07-02T04:42:53.430 に答える
1

単一のIDでのIDの衝突を回避する唯一の本当に安全な方法は、サーバーが常にIDを割り当てることです。POSがオフラインになった場合は、販売をローカルで記録するためにローカルIDと一時IDを割り当て、POSがオンラインに戻ったら、サーバーから実際のIDを取得し、トランザクションを送信する前にローカルIDを実際のIDに変更します。 。私はかつて、クライアントが作成したIDを示すために負の数を使用し、サーバーが作成したIDを示すために正の数を使用するシステムを持っていました。サーバーが負のIDを受信すると、サーバーはそれを一意に作成されたサーバーIDに変更し、そのIDをクライアントに返します。これにより、クライアントはデータベースを実際のトランザクションIDで更新できます。

グローバルに一意のクライアント定義IDが必要な場合、各POSクライアントには、マルチパート複合IDの一部となるサーバー割り当てのuniqueIDが必要です。次に、各クライアントは独自のカウンターを維持できます。このカウンターは、一意のクライアントIDと組み合わせると、常にグローバルに一意のIDになります。これは、すべてのクライアントに一意に割り当てられるclientIDである点を除いて、branchIDの概念を拡張したものであるため、各ブランチに複数のPOSクライアントを配置できます。clientIDの割り当ては、クライアントのセットアップ時に手動で行うことも、セットアップまたは初期化プロセス中にサーバーに一意のclientIDを要求することでより動的に行うこともできます。

このようなテクニックがあなたにとって最も実用的であるかは、ここで説明したよりもはるかに多くのシステムに依存するため、その知識に基づいて選択するか、システムがどのように機能するかについて詳しく説明する必要があります。もっと助けるために。

于 2011-07-02T10:25:03.580 に答える
0

あなたが説明した複合キーは、この問題の良い解決策です。分散した状況でキーの衝突を回避する必要がある場合は、GUIDを使用する傾向があります。

于 2011-07-02T04:41:47.377 に答える