2

初投稿です、よろしくお願いします。

注: エントリ #20856 (タグ付けの実装方法) を確認しましたが、検討しているタグの方法がアプリの組織固有のものであるため、これは異なると感じています。誰かが私が行く方向を確認したり、他のオプションを指摘したりできることを願っています.

(背景) 私たちは、さまざまな組織がさまざまな場所にある在庫を可視化するための Web アプリケーションを構築しています。データベースにはユーザー、組織、サイト、およびアイテムが保存され、サイトおよびアイテムから組織へのリンクがあり、どのアイテム/サイトをどのユーザーに表示するか (組織に基づいて) を決定できます。

2 つ (またはそれ以上) の組織がポータルを使用して、(たとえば) ロサンゼルス倉庫のウィジェット A の在庫状況を確認したいというのはよくあることです。その部分は問題ありません。ただし、さまざまな組織もウィジェット A に関する固有の情報を追跡しています。たとえば、組織 1 は、各アイテムの色、量、主要なベンダーを追跡したいと考えています。組織 2 は、各アイテムの色、在庫タイプ、在庫サイクル、購入者コードを追跡したいと考えています。これらすべての可能なフィールドをテーブルにロードしてから、どの組織がどのフィールドを使用しているかを把握しなければならない状況を避けたいと考えています。

タグの行に沿って何かを使用することを検討していますが、タグ カテゴリを追加し、タグ カテゴリを組織レベルで定義するようにします。したがって、基本的なテーブル構造は次のようになります。

表: OrgTagCategory
フィールド: OrgId、TagCategoryId、CategoryTitle

表: OrgTag
フィールド: OrgId、TagCategoryId、TagId、TagTitle

表: OrgItemTag
フィールド: OrgId、ItemId、TagId

次に、ユーザーがメイン ダッシュボードにログインすると、グリッドには適切な項目フィールドがグリッドの列として含まれます。したがって、上記の例から、組織 1 には、アイテム番号、説明 (すべてが表示されます)、色、数量、および主要ベンダーが表示されます。組織 2 には、アイテム番号、説明、色、在庫タイプ、在庫サイクル、購入者コードが表示されます。

私はこれを考えすぎていますか、それとも私が見逃しているこれを行うためのより簡単な方法はありますか? すべての考え/フィードバックを心から感謝します。

4

3 に答える 3

1

それは問題ないはずですが、OrgId冗長に保存しています。また、タグと組織の間にいくつかの重複がある可能性があります (現実的には、おそらく多くの重複があります)。

これが私がそれを行う方法です：

  • 表: 組織タグ

    フィールド: OrgId、TagId

  • 表: タグ

    フィールド: TagId、TagTitle

  • 表：アイテムタグ

    フィールド: ItemId、TagId

このようにして、各組織は関心のあるタグに関連付けられますが、冗長なタグはありません。複数の組織で使用される特定のタグは、同じ TagTitle を持つ Tag の複数の行ではなく、OrgTag の行の束を取得します。

OrgTagCategory組織ごとに複数のタグ カテゴリがある場合にのみ、テーブルが必要になります。ただし、この追加の関連付けを要件として説明していません。

于 2009-11-11T02:38:12.990 に答える
1

あなたの説明に基づいて、単純化されたモデルをスケッチし、それを観測パターンと組み合わせました。これにより、さまざまなアイテムのプロパティと、それらを表示するためのユーザー設定を追跡できるようになります。確かに、Preferenceテーブルは大きくなる可能性がありますが、とにかくデータをどこかに保存する必要があり、SQL を使用してデータを取得できるため、ビジネス レイヤーが簡素化されます。

-組織と個人は、ユーザーのタイプです。table にはすべてのユーザーUserに共通の列があり、およびtable にはそれぞれに固有の列があります。 - 在庫品目(ウィジェット クラス) は、複数のサイト(倉庫)で見つけることができます。サイト_OrganizationPerson
多くのアイテムを保管します。
- 1 つのアイテムは 1 人のユーザーに属します。ユーザーは多くのアイテムを所有できます。
-測定と特性は観察の一種です。測定値は、高さのような数値観測です。特性は、色のように記述的な観察です。
-観測は特定のタイプ(身長、体重、色) であり、同じタイプの観測が多数存在する可能性があります。 - 1 つのアイテム(ウィジェット クラス) に多くの観測値を含めることができます。
観察は 1 つの項目のみに関連します。
-ユーザーは、多くの観察結果を表示することを好む場合があります。オブザベーションは、多くのユーザーに (表示するために)好まれる可能性があります。更新観測タイプ をタグ付けすることで、アイテムの詳細 (観測) へのユーザーのサブスクリプションを簡素化できます。たとえば、高さ、重量、幅には次のタグが付けられます。他のタグとしては、accounting_interest、tracking_specific などがあります。ユーザーはタグのみを購読します。タグは、すべてが最上位の階層を形成します。- 1 つの観測タイプ

orgspecific_model_01




(身長、体重、色) は多くのタグを持つことができ、1 つのタグは多くの観測タイプに属します。
- 各タグは、階層を形成する 親タグを持つことができます。
-ユーザーは、通常監視する一連のタグの設定を保存します。UPDATE 2 これで、誰が誰で、誰が何を所有しているかを整理できます。この変更では、ユーザー(現在は個人) が複数の組織(いくつかのアルバイトまたは契約を持っている) で働くことができます。アイテムは組織に属しています

orgspecific_model_01A


今。ログインしたユーザーは、所属するすべての組織のすべてのアイテムを表示できます。

orgspecific_model_01B

于 2009-11-11T15:41:17.123 に答える
0

これに関する私の最初の簡単な意見は、これがダッシュボードの特定の組織に特定のフィールドを「表示」することに限定されている場合は、アプリ側で処理する方がよいということです。「タグ付け」の他の使用法がある場合は、明確にしてください。

これは簡単なアプローチです - フィールド [OrgDashboardFields] を Org マスター テーブルまたは OrgItem テーブルに格納できます。これは、ダッシュボードに表示されるフィールドのコンマ (',') 区切りのリストになります。実行時に [OrgDashboardFields] フィールドを取得し、アプリでカンマ区切りのリストを解析して、それに応じてダッシュボード グリッドを動作させます。

または、動的クエリ フレームワークがある場合は、[OrgDashboardFields] フィールドに基づいて動的 SQL クエリを作成し、純粋に組織固有の目的の結果を取得できます。

于 2009-11-11T05:42:10.903 に答える