0

レイアウトは次のとおりです。

  • SQLServerデータベースを使用して内部ASP.NETWebアプリ（VB.NET）を開発しています。
  • 私のユーザーは厳密に内部であるため、自動認証には「Windows」方式を使用しています。
  • 私には4つのユーザーロールがあり、それぞれに独自の動的な設定セットがあります。
  • ボーナス：各ユーザーは複数の役割、したがって複数のプロファイルを持つことができます。

私の広範な調査から、ユーザープロファイル設定を保存するための次の2つの方法を決定しました（どちらも「HOW？」という質問を促します）が、どちらが最適かはわかりません（ある場合）。

  • プロファイルと関連する設定をDBに保存します（どの構造を使用しますか？予備的なマッピングから、少なくとも4つのテーブルを作成しましたが、これらのテーブルは非常に管理不能で保守不可能になり始めています）
  • 組み込みのASP.NETメンバーシップおよびプロファイルオブジェクトを使用しますか？（これに関する優れたチュートリアルが見つからないようです。この方法でもDBサポートが必要ですか？繰り返しますが、どのテーブル構造を使用しますか？）-この可能な解決策に最も興味があります

例：

私の最も複雑なユーザーグループには、ユーザーに関連付けられているすべての（ユーザーが選択した）製品のプロファイルを保存する機能が必要です。私がプロダクトマネージャーであり、自分が担当している選択したすべての製品をアカウントに表示したいとします。明らかに、私の役割の各メンバーは、異なる製品と異なる数量などを持っています。おそらく、ユーザーページの設定（検索、並べ替え、順序のデフォルトなど）は、補助設定テーブルを参照して、汎用テーブルに格納できます。ある種の「外部キー」として機能する可能性のある特別なレコードを介してリンクできる奇妙なもののために。

リクエストに応じて、テーブルプランに関する私のアイデアの1つは次のとおりです。

    Users (ID, Username, RoleID)
    Roles (ID, RoleName, Description) --Lookup Table
    Settings (ID, Name, Value)
    UserSettings (ID, UserID, SettingID) --Junction Table

次に、疑問が生じます。

  1. 行と列をいつ使用する必要がありますか？
  2. 設定ごとに列を使用すると、データ型を定義できますが、列数が制御できなくなる可能性があります。一方、設定ごとに行を使用する場合は、はるかに理にかなっていますが、設定のデータ型を制御できなくなります。
  3. UserSettingsテーブルを省略し、代わりにUserID外部キーを使用してSettingsテーブルの各設定のname = valueペアレコードを追加する必要がありますか？
  4. などなど...

私の理想的な答え：

ご覧のとおり、私には多くの質問があり、一見ほとんど役に立たないようです。誰かが私のために簡単にそれを分解することができれば、私はそれを愛するでしょう。あなたの専門的な推奨事項とそれを実装する方法に関するいくつかの非常に簡単なヒントを教えてください（つまり、使用するASP.NETオブジェクト、およびそれらのオブジェクトが私の複雑なプロファイルを管理するためのメカニズムをどのように提供するか）

4

1 に答える 1

1

これはほぼ確実にデータベースでモデル化する必要があると思います。

ユーザーに関連付けられた製品は、実際には役割ベースのものではありません。そのため、マネージャーだけがその関係を持っていると言っていても、役割から大きく独立している必要があります。ロール内のユーザーのみがそのリンケージを持ちますが、それは、ユーザーとロールに依存するリンケージがない限り、アプリケーションレベルで強制する可能性のある高レベルの制限または外部キーではなく、より高いレベルの制約のようなものです。

次に、マネージャーとして行動しているユーザーが特定の製品を持っているかもしれませんが、セールスマンとして行動している場合は、別の製品を持っているかもしれません。次に、ロールもリンク テーブルに含まれます。リンク テーブルの行には、リンケージ自体だけでなく、リンケージに関する属性がある場合もあります (通常は、発効日やアクティブ/無効フラグなど)。

于 2011-08-24T03:23:23.047 に答える