2

「クライアント」とは、サービスにサインアップした企業または組織を意味することに注意してください。

バグ追跡アプリケーションを作成しています。アプリケーション インスタンスとデータベースの両方に関して、マルチテナント アプローチを採用することにしました。

したがって、すべてのクライアントからのエントリを含む 1 つの巨大なバグ テーブルがあります。バグ ID は ID 仕様です。このため、任意のクライアントのユーザーがバグを追加すると、増分されます。タスクを 3 つだけ追加したクライアントの場合、タスク ID は #45、#49、#53 の可能性があります。これは、他のクライアントのユーザーがその間にタスクを追加した可能性があるためです。

これはユースケースの観点から許容できますか?

場合によっては、クライアントが最新のバグ ID をバグ数の大まかな目安として使用することがあります。しかし実際には、システム内の TOTAL バグになります。または、最初のバグが #51134 から始まる場合は、驚くことでしょう。

一方、この特定の ID を「舞台裏で」持っていて、各クライアントの「可視」ID を個別に計算すると、番号が順番に表示されます。しかし、参照バグ ID を URL のパラメーターとして渡す場合、ユーザーに表示される ID は一意ではないため使用できません。ClientID - BugID の組み合わせはエレガントではないと思います。ユーザーが UI で 1 つの ID を表示し、URL で別の ID を表示するため、元の ID 仕様値を使用すると混乱が生じるのではないかと心配しています。言うまでもなく、開発者は ID を変更して URL を使用しようとし、それが失敗するのを観察します。

この問題を解決するにはどうすればよいですか? メンテナンスとアップグレードのプロセスがちょっと怖いので、マルチデータベースのアプローチには行きたくありません。

4

3 に答える 3

1

ここでは、最小の驚きの原則が適用されると思います。何をするにしても、一貫性を保つ必要があります。URL スキームを変更できない場合は、連続していない ID が唯一の実行可能な解決策になります。個人的にはこれに関する問題は見られません。ほとんどのバグ トラッカーは、特定の期間に報告されたバグの数や、特定のプロジェクトでのバグの数などのレポートを生成できます。

少し関係ない話ですが、職場ではすべてのプロジェクトで単一のバグ追跡システムを使用しています。システム全体として、どのプロジェクトのバグに対しても 1 つの増分 ID があります。問題が発生したことはありません。

于 2011-05-14T13:43:52.813 に答える
0

一般的な経験則として、できる限り代理キー (IDENTITY 値) をユーザーに表示しないでください。人間は最終的に、自分が知っている何かを変更したいと思うので、主キーの値を知る必要はありません...

人間が消費できる識別子を生成するというアイデアは、あなたが言及したように、システムのキーのように使用しないでください。代理キーをキーとして使用します。(通常、URL 文字列でキーを渡す方法があります...) むしろ、人間が消費するキーを最初の生成後に表示フィールドとして扱います。

クライアント名の略語、クライアントの会社の略語、日付/時刻の一部、またはコンテキスト ( ) に対する別のクエリで決定したその他のカウンター、SELECT MAX(?) FROM qまたはこれらの組み合わせを連結することを検討してください...

幸運を!

于 2011-05-14T13:49:13.950 に答える
0

私が言及したい特別なケースの 1 つ: これが公開 Web サイト、つまり公開サポート ページなどであり、顧客が電話でサポート チケット番号を提供する場合 (つまり、通信媒体の中断)、 「インテリジェント」ID。たとえば、5 つの数字 + チェックサム。これにより、オペレーター (またはシステム) は、チケット番号の読み間違いをより簡単にチェックできます。

于 2011-05-14T14:03:06.947 に答える