2

求人情報を格納する既存のデータベース設計があります。

"Vacancy" テーブルには、"役職"、"説明"、"給与範囲" など、すべてのクライアントに共通する多数の固定フィールドがあります。

「マネージャー名」、「勤務時間」など、クライアントが自分で設定できる「カスタム」フィールドの EAV デザインがあります。フィールド名は「ClientText」テーブルに保存され、データは VacancyId、ClientTextId、および Value とともに「VacancyClientText」テーブルに保存されます。

最後に、欠員がいる場所/オフィス、必要なスキルのリストなどで、欠員をカスタムタグ付け/分類するための多対多のEAV設計があります。これは、タグのタイプを一覧表示する「ClientCategory」テーブル、「Locations、Skills」、各カテゴリの有効な値を一覧表示する「ClientCategoryItem」テーブル (例: 「London,Paris,New York,Rome」、「C#、 VB、PHP、パイソン」。最後に、欠員のために選択された各アイテムの VacancyId と ClientCategoryItemId を含む "VacancyClientCategoryItem" テーブルがあります。

クライアントが追加できるカスタム フィールドまたはカスタム カテゴリの数に制限はありません。

現在、既存のシステムと非常によく似た新しいシステムを設計していますが、クライアントが持つことができるカスタム フィールドの数を制限する機能があり、ゼロから構築されているため、対処するレガシーの問題はありません。

カスタム フィールドの場合、私のソリューションは単純です。Vacancy テーブルに CustomField1-5 という名前の 5 つの追加の列があります。これにより、EAV デザインの 1 つが削除されます。

私が苦労しているのは、タグ付け/カテゴライズのデザインです。クライアントのタグのカテゴリ/タイプを 5 つに制限するとします。可能な値「CustomCategoryItems1-5」をリストする 5 つのテーブルを作成し、さらに多対多のテーブル「VacancyCustomCategoryItem1-5」を 5 つ作成する必要があります。

これにより、10 個のテーブルが既存のシステムの 3 つのテーブルと同じストレージを実行することになります。

また、5 つではなく 6 つのカスタム カテゴリが必要であるという点で要件が変更された場合 (非常に禁じられています)、これにより多くのコードが変更されます。

したがって、そのようなデータの保存により適した DB 設計パターンを誰でも提案できます。私は EAV アプローチに固執することに満足していますが、既存のシステムは、そのような設計に関連するすべての通常のパフォーマンスの問題と複雑なクエリに遭遇しました。

アドバイス/提案は大歓迎です。

使用される DBMS システムは SQL Server 2005 ですが、特定のパターンで必要な場合は 2008 もオプションです。

4

3 に答える 3

1

この質問/回答を見てください。観測パターンを説明します。5 つのテーブルを使用し、「標準」RDBMS で実装できます -- Sql Server 2005 で十分です。エンティティが持つことができるカスタム プロパティ (観察) の数に制限はありません。

編集

プロパティにタグ (カテゴリ) が必要な場合は、こちらをご覧ください。

于 2010-06-10T12:36:48.493 に答える
1

XML 列の使用について考えたことはありますか? XSL を使用して、すべての制約を宣言的に適用できます。

EAV の代わりに、スキーマ (またはスキーマのコレクション) によって検証された XML データを含む単一の列を用意します。

于 2010-06-10T11:25:57.220 に答える
0

カスタム フィールドを Key-Value テーブルに保存しないのはなぜですか?

| vacancy ID | CustomFieldType | CustomFieldValue |

次に、タイプごとに可能な値をリストする補助テーブルを用意し (1 テーブル)、空室タイプごとに可能なタイプである可能性があります (元の ClientCategory のようです)。

于 2010-06-10T11:34:05.863 に答える