3

たとえば、文字列、日付、または XML データ型など、複数の型にできるフィールドがあるとします。

これをデータベースに保存する方法は 2 つあります。

1- 文字列型フィールド + 型を定義するフィールドを使用: 「型認識」ソート機能を失い、キャストが必要

2- 個別のテーブル (StringValues、DateValues、Decimal、XML ...など): 値を指す外部キー + タイプを定義するフィールド : なんとなく複雑、パフォーマンス

2 番目の方法は、一意の値のみが保存されている場合に特別な利点があります。これはインデックスとして機能します。

何か心当たりはありますか？

注1: ​​できれば、MS SQL Server 2008 と Linq2SQL に基づくプロジェクトを検討してください。

注 2: EAV の実装方法については別の質問で説明するかもしれませんが、リレーショナル ストレージでの EAV について質問しています。

注 3: タイプは変更される可能性がありますが、頻繁ではありません

4

5 に答える 5

5

テーブルが複数の属性の値を行ごとに 1 つの値で格納するEAVソリューションを設計しているようです。

EAV は非リレーショナル設計です。リレーショナル データベース設計の適切なルールに関して、これを行う「正しい」方法はありません。

適切な設計は、各属性を1 つのテーブルの個別の列に格納することです。各列に適切なデータ型とわかりやすい名前を付けます。各列には同じ論理型の値のみを格納します。

動的な属性が必要な場合は、非リレーショナル データ管理ソリューションを使用してください。

于 2009-08-27T22:53:05.020 に答える
2

XMLデータ型の使用を検討できますか？その場合は、属性/要素を使用してタイプを定義できます。

<string>My string value</string>
<date>24-Nov-1976</date>

または、

<val type="System.String">My string value</val>
<val type="System.Date">24-Nov-1976</val>

SQL Server 2005+は、ニーズをサポートする可能性のあるXMLインデックス作成を適切にサポートしています。

LinqからSQLの観点からは、タイプを特定のデータ型にマップできる軽量のクラスを作成できる可能性があります。XMLの逆/シリアル化はここでのオプションかもしれません。

于 2009-09-22T02:43:34.703 に答える
2

私は 2 番目のオプションを使用し、テーブルの状況の複雑さをいくつかのビューで隠します。そうすれば、柔軟性が向上しても、アプリケーションは変更する必要なくビューを指すことができ、基になるテーブルを少しきれいなものに再配置できます。

于 2009-09-22T02:25:41.580 に答える
1

可能なタイプの数が少ない場合は、オプション 2 (追加のテーブル + 外部キー) を使用するか、オプション 3 を使用します。

オプション 3: 各タイプのフィールドと、関連するフィールドを定義する列挙型フィールドを含む 1 つのテーブルを使用します。

考えられる型の数が多いか一定でない場合は、オプション 1 (文字列) を使用します。日付を文字列に YYYY-MM-DD-HH-MM-SS として格納して、並べ替えを保持できます。

于 2009-09-23T21:15:41.977 に答える
1

これが質問にうまく答えるのに十分な詳細であるかどうかはわかりません。2 つのタイプのケースについて文字通り質問している場合は、各タイプの列と識別子を含むテーブルを検討することもできます。「正しい」答えは、サポートされる個別の型の数、速度とスペースの制約などの詳細に依存する場合があります。

最も安価なアプローチが最良のアプローチであると主張する人もいるかもしれません。具体的には、理解と維持に必要なコストが最小になると思われるアプローチ (多くの場合、TCO の 60% まで) です。

これをしないことに関するすべてのアドバイスに関して、可能であれば同意します。一方、SharePoint は、それが不可能ではないことを示す 1 つの例です。幸運を！

于 2009-09-22T02:16:09.427 に答える