1

この質問は、コードよりもアーキテクチャとアイデアに関するものです。

問題: すべてを格納するバックエンドのメイン DB を用意しましょう。次に、ユーザー/デバイスに関連するデータのみを格納するフロントエンド ローカル データベース (SQLLite など) があります。

ユーザーはフロントエンドでデータを作成できます。ただし、複数のユーザーが同時に同じ種類 (つまり、レシート) を作成することができ、単純な int 自動インクリメント PK を使用すると、バックエンドで衝突が発生します。

提案された解決策は次のとおりです。複合 PK を使用します。ここで、PK は次のもので構成されます。 -autoincrement integer -device ID -user ID

ここで、論理的には、deviceID と userID はデバイスとユーザーのテーブルへの FK である必要がありますが、いくつかの理由から、すべてのデバイス/ユーザーを各フロントエンド デバイスに格納することは実際的/不可能であるため、FK は問題を引き起こします。

これに対する提案された解決策は、フロントエンドで FK 要求を省略し、バックエンドでのみデータの整合性をチェックすることですが、正直なところ、リスク/ゲインがそれだけの価値があるかどうかはわかりません。

誰かがこの時点に行ったことがありますか、および/または展開後に何らかの経験がありますか? あなたの考えは何ですか？どうもありがとうございました。

4

1 に答える 1

0

ヴラド、

あなたが対処しようとしている難しい問題は、デバイスがすべてのデバイスで一意の識別子をどのように生成できるかということだと思います。その質問に対する過去の答えは、「デバイス ID」、「タイムスタンプ」、乱数などの一意の識別情報を組み込んだ「Global Unique IDentifier」(GUID) または「Universally Unique IDentifier」(UUID) を作成することでした。 . これを行うための IETF 標準は、RFC4122にあります。

したがって、ほとんどのデータベース ベンダーは、これらの一意の識別子のいずれかを返すために、少なくとも UUID() または GUID() SQL 関数を提供しています。ところで、SQLLiteが提供するかどうかはわかりませんが、 SequelSphereDBが UUID() 関数を提供することは知っています。最終的に、これらを使用して行の一意の識別子を作成できます。

したがって、数値、デバイス ID、およびユーザー ID で構成される主キーの組み合わせを使用する代わりに、行の作成時にオンザフライで生成された UUID を格納する単一の列 CHAR(36) を使用します。

UUID 長所:

  • 単列
  • 他のデバイスに接続する必要なく、クライアントで生成
  • 一意であることが「保証」されているか、少なくとも代替の可能性よりもはるかに優れています。

UUID 短所:

  • 列ストレージが大きい: CHAR(38)。
  • 生成は、代理キー ワンアップ ジェネレーターと比較して低速です。
于 2012-11-29T22:11:33.183 に答える