2

データベースでこれらの関係をどのようにモデル化しますか?

PageElements を含むことができる Page エンティティがあります。

PageElement は、たとえば Article や Picture にすることができます。Article テーブルには、明らかに、Picture 以外のメンバー/列があります。記事には ie が含まれる場合があります。「Title」、「Lead」、「Body」列はすべて nvarchar 型ですが、Picture には「AltText」、「Path」、「Width」、「Height」などがあります。私はこれを拡張可能にしたいのですが、3 か月でどのような PageElements が必要になるかは誰にもわかりません。したがって、PageElementTypes テーブルが必要になると思います。

リレーションシップについては、次のようなテーブルはどうでしょうか。

Id を持つページ、およびその他の巨大なジャンボ。(作成日、表示可能、その他)

PageIdと PageElementId を持つ Pages_PageElements。

Id とPageElementTypeIdを持つ PageElements と、さらに巨大な (SortOrder、Visibility など)。

ID と名前を持つPageElementTypes (たとえば、"Article"、"Picture"、"AddressBlock")

ここで、すべての Articles、Pictures、AddressBlocks テーブルに PageElementId 列を作成して、作業を終了する必要がありますか? これは単純な 1 対 1 の関係であるため、これでうまくいくはずですが、どういうわけか何かを見落としている可能性があります。

ファローアップ：

個別の属性を使用した以下の推奨ソリューションでは、すべての属性を同じタイプとして保存する必要がありますか? 1 つの PageElement の属性が nvarchar(255) で、一部が nvarchar(1000) の場合、一部が整数の場合はどうなりますか?

EAV の方法を取得した場合、そこにあるすべての異なるデータ型の属性値を保持するために、大量のテーブルを作成する必要があります。

4

5 に答える 5

2

一般的な 2 つの選択肢は、Single Table InheritanceとMulti Table Inheritanceです。他のアプローチには、私が使用したことのない具象クラスごとにテーブルを用意することや、属性定義があらゆる種類のスキーマではなくデータに移動されるメタテーブル実装と呼ばれるものが含まれます。

私は一般的にSTIで良い経験をしてきました。クラスや属性が多すぎるとは思わないのであれば、それが最も簡単な解決策です。シンプルは私の本ではとても良いです。

実行時にユーザーが新しいページ要素タイプを作成する必要がない限り、私はメタテーブルのアプローチやそれに似たものは避けたいと思います。私の経験では、そのようなコードはすぐに泥沼になり、開発者によって定期的に更新されるより具体的な実装と比較して、ほとんど価値がありません。

于 2008-12-02T10:10:21.210 に答える
1

ページ要素を構成したのと同じように、ページ要素に関連付けられた属性を構成する必要があります。

したがって、拡張可能なページ要素とその属性である 2 つの項目があります。

次の表をお勧めします。

ページ: ページ ID | ...

ページ要素: ページ要素 ID | エレメント タイプ ID | ページ ID | ...

ページ要素タイプ: 要素タイプ ID | ページ要素タイプ ラベル

ページ要素の属性タイプ: 属性タイプ ID | エレメント タイプ ID | 属性ラベル

ページ要素の属性: ページ要素 ID | 属性タイプ ID | 属性値

ページ要素属性タイプテーブルには、要素に関連付けられた属性のリストが含まれます。例 ：

属性タイプ ID 1 | 記事 | "題名"

属性タイプ ID 2 | 記事 | "鉛"

属性タイプ ID 3 | 写真 | 写真 | 「代替テキスト」

ページ要素属性テーブルには、ページ要素に関連付けられた属性の実際の値が格納されます。例 ：

ページ要素 ID 1 | 属性タイプ ID 1 | 「誰もがレイモンドを愛している」

ページ要素 ID 2 | 属性タイプ ID 3 | "世界地図"

于 2008-12-02T09:52:29.700 に答える
0

私は自分が得たもので行くと思います.EAVは私にとって選択肢ではありません. 私が今得たのは、ややハイブリッドなアプローチです。

于 2008-12-02T12:23:43.530 に答える
0

普遍的な解決策は次のとおりです。

PageElementType: ID, Name, [Mumbo Jumbo]
PageElementTypeParameter: ID, PageElementTypeID, [Mumbo Jumbo]
Page: ID, [Mumbo Jumbo]
PageElement: ID, PageElementTypeID, [Mumbo Jumbo]
PageElementParameters: ID, PageElementID, PageElementTypeParameterID, Value, [Mumbo Jumbo]

人間の言葉で言えば、ページ要素タイプのテーブルと、各ページ要素の可能なパラメーターをリストする関連テーブルがあります (画像の SRC と ALT、記事の TEXT など)。

次に、すべてのページを含むテーブルがあります。各ページの要素をリストする関連テーブル。各要素のパラメーター値を一覧表示する表。

于 2008-12-02T09:24:40.130 に答える
0

私はあなたとは異なる命名規則を使用していますが、これは基本的に私がすることです:

PageElementType(PageElementTypeID, PageElementTypeName)

PageElement(PageElementID、PageElementTypeID)

Article(記事ID、ページ要素ID、...)

Picture(PictureID、PageElementID、...)

ページ(ページID, ...)

PageHasPageElement(PageHasPageElementID, PageID, PageElementID) => {PageID, PageElementID} は一意です

これは私がしていることであり、かなりうまく正規化されており、うまく機能しているようです。

于 2008-12-02T09:24:41.817 に答える