2

システム内の 2 つの異なるプロファイル (私の場合は教師と生徒) のプロファイル テーブルを一般化することは理にかなっていますか? 私はこれを行っており、設計アプローチに関する一般的な健全性チェックが必要です。返信ありがとうございます。以下の背景：

教師と生徒の両方を持つ Web システムを構築しています。どちらもシステムにアカウントを持っています。どちらもシステムにプロファイルがあります。

私の質問は、これらのプロファイル テーブルのテーブル デザインについてです。

教師のプロファイルは、関連付けられているメタデータに関してかなり静的です。各教師には、その個人に関する情報 (学校、学位など) を公開する一定数のフィールドがあります。しかし、学生は別のケースです。Windows サービスを使用して、学生に関するさまざまなデータを無限の Excel スプレッドシートから取得しています。

データがデータベースに移動され、フィールドが学生のプロファイルに関連付けて表示されます。したがって、学生一人一人のプロフィールに非常に異なる分野がある可能性があります。

私は当初、次の 3 つのテーブルの概念から始めました。

アカウント

AccountID

教師プロフィール

TeacherProfileID
AccountID
SecondarySchool
University
YearsTeaching
Etc...

学生プロフィール

StudentProfileID
AccountID
Header
Value

StudentProfilesテーブルには、Excel スプレッドシートの列ヘッダーの名前と関連する値が保持されます。

それ以来、添付の ERD イメージごとにプロファイルをより一般的に扱うために、デザインを少し進化させました。教師と生徒の「ヘッダー」は という名前のテーブルに保存され、ProfileAttributeTypes応答 (Excel ドキュメントから、または Web フォームの入力フィールドを介して) がProfileAttributesテーブルに配置されます。このようにして、生徒と教師の両方のプロファイルをプロファイル フィールドの動的なフローに関連付けることができます。「パーミッション」テーブルは、学生または教師のどちらを扱っているかを示します。

成長が早いシステムなので、しっかりと基盤を固めたい。この設計についてフィードバックをお寄せいただけますでしょうか。それが正しいと思われるかどうか、または問題が発生する可能性があるかどうかをお知らせください。

前もって感謝します。

プロフィール

4

3 に答える 3

1

お持ちのデザインはあまり良くないと思います。モデルには、ユーザーとエンティティの概念が混在しています。

ここから、より適切な設計が始まります。

t_ユーザー

t_User_Settings (プロファイル)

t_権限

t_アクション

t_学生

t_先生

t_Student_Attributes

t_Teacher_attributes

ユーザー関連の項目/属性は t_User または t_User_Settings に属します ドメイン関連の項目/属性は t_Teacher/t_Teacher_Attributes または t_Student/t_Student_Attributes に属します

外部キーを介して、ドメインの概念 (教師/生徒) をユーザーの概念に関連付けることができます。または、t_Teacher_User + t_Student_User テーブルを作成できます。

テーブル名を読むだけで、何がどこにあるのかを正確に知る方法に注目してください。

于 2012-04-15T00:58:49.730 に答える
1

プロパティバッグアプローチ

提案するデータ モデルは、「プロパティ バッグ」 (プロファイルのキー値項目のコレクション) に依存しています。このモデルの優れた点は、データ モデルを変更せずにプロパティを拡張できることです。

欠点は、データを頻繁に「ピボット」する必要があり、テーブル (およびインデックス) のサイズが急速に大きくなることです。(私の経験: 50,000 レコードのキーあたり 200 プロパティ = 1,000 万のプロパティで、プロパティの変更の追跡に関するものは何もありません。)

このモデルは、主に 1 つの特定のプロパティに対してキーのクエリを実行する必要がある場合に推奨されます。「数学の学位を持っている人は何人ですか?」のようなクエリを考えてみてください。ここで、math degree はプロパティ キーです。

Xml フィールド アプローチ

この戦略ではProfiles、プロパティのリストを xml 形式で取得する「xml」フィールドをテーブルに追加します。このモデルでは、データ モデルを変更せずにプロパティの数を拡張することもできます。

Sql Server は、(xpath クエリ、xml インデックスなどを介して) このようなフィールドを非常に適切にサポートしており、もちろん、xml フィールドに好きなものを格納できるシンプルなデータ モデルを維持できるという利点があります。

このモデルは、フィールド コンテンツが全体として置き換えられる場合に推奨されます。xpath クエリを使用して xml フィールドのデータを変更できますが、非常に低速です。

スパース列

スパース カラムシステムはSQL Server 2008 で導入され、データが密集していないテーブルに多くの異なるフィールドを作成できるようになりました。利点は、1024 の制限よりも多くの列を作成できることと、入力されていないフィールドが入力されていないときにスペースを占有しないことです。

欠点は、可能なすべてのフィールドを前もって知る必要があることです。そうしないと、新しいフィールドに遭遇するたびにデータ モデルが変更されることになります。このモデルは、テーブルにほとんど空の列がある場合に最適です。

どのアプローチを取るべきですか？

これは難しい部分です。すべては、データで何をしたいかによって異なります。私の経験では、プロパティ バッグのアプローチは、小さなデータ セットで、プロパティの変更を追跡する必要がない場合に適しています。(1 か月後にテーブルに 10 億を超えるレコードがある状況を見たことがあります)

Xml フィールドは、フィールドの特定のコンテンツに対して頻繁にクエリを実行する必要がある場合に厄介な問題になる可能性がありますが、「キーごと」にのみ要求される情報を格納するのに最適です。

スパース列は、列に入力されるレコードが 30% ～ 40% 未満の場合に適しています。

追記: 常に値を更新する必要があるため、データ モデルに「教育年数」などを保存することは悪い習慣と見なされます。「授業開始年」を保存してデルタを計算するとよいでしょう。

于 2012-04-09T20:23:28.080 に答える
0

私の経験では、データ モデルのサニティ チェックを行う最善の方法は、必要になる可能性が高いクエリ/DML を作成することです。

Filip de Vos が書いているように、あなたの「プロパティ バッグ」アプローチは、典型的なリレーショナル クエリには簡単には向いていません。

一方、初期設計では、設計時にスキーマが異なるか不明なデータの保存に関する問題が解決されます。

実際には、通常、典型的なリレーショナル モデルで "固定" のものをモデル化し、プロパティ バッグまたは XML ドキュメントを使用して可変ビットをモデル化することになります。設計時にスキーマを明確にできる場合は、「スパース列」も役立ちます。

于 2012-04-17T10:35:51.470 に答える