0

今回は柔軟に対応し、データベースに保存したい連絡先情報をユーザーが決定できるようにしようと考えました。理論的には、たとえば、次を含む単一の行として表示されます。名前、住所、郵便番号、カテゴリ X、Listitems A.

ユーザーが使用できるデータ型を定義する
FieldTypeテーブルの例:

FieldTypeID, FieldTypeName, TableName
1,"Integer","tblContactInt"
2,"String50","tblContactStr50"
...

FieldDefinitionテーブルで自分のフィールドを定義するユーザー:

FieldDefinitionID, FieldTypeID, FieldDefinitionName
11,2,"Name"
12,2,"Address"
13,1,"Age"

最後に、実際の連絡先データをデータ型に応じて別のテーブルに保存します。マスター テーブルには ContactID のみが含まれます

tbl連絡先:

ContactID
21
22

tblContactStr50 :

ContactStr50ID,ContactID,FieldDefinitionID,ContactStr50Value
31,21,11,"Person A"
32,21,12,"Address of person A"
33,22,11,"Person B"

tblContactInt :

ContactIntID,ContactID,FieldDefinitionID,ContactIntValue
41,22,13,27

質問:次のように、これらのテーブルの内容を 2 つの行で返すことは可能ですか?

ContactID,Name,Address,Age
21,"Person A","Address of person A",NULL
22,"Person B",NULL,27

COALESCE および Temp テーブルの使用を検討しましたが、これが可能かどうか疑問に思っています。たとえそうであっても、データストレージとユーザー定義オプションの利点のためにパフォーマンスを犠牲にしながら、複雑さを追加しているだけかもしれません。

どう思いますか？

4

1 に答える 1

1

これは良い方法ではないと思います。理由は次のとおりです。

  • 連絡先の1レコードの単純な挿入は、突然n挿入になります。たとえば、連絡先のvarchar、nvarchar、int、bit、datetime、smallint、およびtinyintデータを格納する場合、データ型固有のテーブルに7回挿入され、メインヘッダーレコードに+1が挿入されます。
  • 同様に、クエリは自動的に7つのテーブルを参照し、完全な詳細を取得するためだけに6つのJOINが関与します

個人的には、「一般的」ではないアプローチを採用する方が良いと思います。単純にする。

更新： 問題は、このような柔軟なソリューションが本当に必要かということです。連絡先データの場合、少なくともコアセットのフィールド（住所行1-n、名、名前など）を格納できることが常に期待されます。ユーザーがその標準データセットの上にカスタム/ユーザー定義可能なデータを保存する方法が必要な場合、それは一般的な要件です。さまざまなオプションが含まれます：

  • すべてのユーザー定義データを格納するためのメインの連絡先テーブルのXML列
  • キーと値のペアのデータを含む1つの追加のテーブルは、最初に話したのと少し似ていますが、程度ははるかに低いです。これには、連絡先のキー、カスタムデータアイテム名、および値が含まれます。

これらはここSOで以前に議論されているので、その質問を掘り下げる価値があります。ちょっと見てみたら、覚えている質問が見つからないようです！

繰り返しを節約するために、キーと値のアプローチの長所と短所について説明しているものを見つけました。
リレーショナルデータベースの
キーと値のペアデータベーステーブルのキーと値のペア

于 2010-04-13T07:00:14.473 に答える