2012-04-21 10 views
0

私は、ユーザーが任意の製品に関するコメントを残すことができるストアウェブサイトを持っているとします。データベース構造、複数のエンティティのための1つの大きなエンティティ

ウェブサイトのデータベースにテーブル(エンティティ)があるとします。「シューズ」、「帽子」、「スケート」としましょう。 私は、すべてのエンティティ( 'shoes_comments'、 'hats_comments'、 'skates_comments'など)ごとに別々の「コメント」テーブルを作成したくありません。 私の考えは、何とかすべてのコメントを大きなテーブルに保存することです。コメントを持つことができるすべてのエンティティのための

table (comments): 
ID (int, Primary Key), 
comment (text), 
Product_id (int), 
isSkates (boolean), 
isShoes (boolean), 
isHats (boolean) 

などのフラグ:これを行うには

一つの方法は、私が考えていること、テーブルを作成することです。

それから私は、SELECTクエリは次のようになり、一部の製品についてのコメントを取得したいとき:

SELECT comment 
FROM comments, ___SOMETABLE___ 
WHERE ____SOMEFLAG____ = TRUE 
    AND ___SOMETABLE___.ID = comments.Product_id 

が、これは必要な機能のためのデータベースを実装するための効率的な方法ですが? 他の方法はありますか?>

答えて

1

コメント用に1つのテーブルを作成し、コメントテーブルに他のテーブルの外部キーを使用することをお勧めします。

+0

私の考えは多少異なります。私はあなたの考えを理解しています:すべてのエンティティテーブルのグローバルコメントテーブルに外部キーを追加します。 –

1

申し訳ありませんが、これは奇妙です。

実際には、それぞれの製品タイプごとに別々の表がありますか?共通のフィールド(名前、説明、価格、商品画像など)を持っていませんか?一般的なフィールドのproduct、外国productへの鍵が、無hasX列のcomments、帽子の製品ラインに固有のフィールドのみでhat:テーブル用として

私の推薦。 hatのプライマリキーはproduct PKまたは個別の一意の値です(外部キーのフィールドをproductに追加する必要があります)。

+0

これは難しいことではありません。しかし私の状況では、私は完全に別々のもの(組織、スタッフ、テクニカル機器)を持つエンティティを持っており、私はそれらのためのコメントを保存する必要があります... –

+0

さて、私はあなたの例で誤解していました、ごめんなさい。それでも、もしあなたがルールをちょっと曲げようとするならば、あなたはただ一つの 'コメント'テーブルしか必要としません。あなたは、私が推測するコメントを持つ各エンティティに対して 'comment'に外部キー列を持つことは望ましくありません。実際の外部キー列がなく、 'comment'に' parent_id'として宣言されている列が1つある場合はどうなりますか?私は '' X''から ''コメント ''への関係は単方向性であると思いますか? 1つの代替案は、各 'X 'が' shoe_x_comment'、 'hat_x_comment'のように' comment'するための結合テーブルを持つことです。 –

0

これを行うには、「正規化」の方法は、1つの以上のエンティティを追加することです(たとえば、「製品」)は(コメントを含む)、靴、帽子、スケートパフォーマンスの考慮事項に加えて

   +-- 0..1 [Shoe] 
       | 
[Product] 1 --+-- 0..1 [Hat] 
    1   | 
    |   +-- 0..1 [Skate] 
    * 
[Comment] 

に共通するグループのすべての特性ここでの欠点は、データモデルには、Productの行がShoeの行とHatの行の両方で参照されることを防ぐものがないことです。

他の選択肢もあります(それぞれの特典には&の脆弱性があります) - あなたは "jpa継承戦略"について何かを読んでみたいと思うかもしれません - あなたの同じ問題について議論するJavaの記事を見つけるでしょう残りの部分を読む)

個人的には、階層内のすべてのエンティティ(私たちの場合は靴、帽子、スケート)に単一のテーブルを使用し、パフォーマンスとシンプルさの祭壇の制約を犠牲にしてしまうことがよくあります靴には必須であるが、帽子やスケートでは必須ではないフィールド)。

+0

テーブル "COMMENTABLE"を作成し、エンティティテーブル(帽子、靴、スケート)から1:1の関係でそれらを接続する状況で、これは機能しますか? –

+0

ええ、それはアイデアです!それに行く前に、あなたはパフォーマンスを考慮する必要があります。例えば、新しい靴を追加するには、2つの挿入ステートメントが必要です(Commentableの場合は1、Shoeの場合は1) - あなたがコメントのIDを持っていて、そのエンティティエンティティに移動するには、エンティティがどのテーブル(靴、ハット、スケートでもよい)で事前にわからないので、(おそらくいくつかの)ユニオン句が必要です。 – giorgiga

+0

ここでのトラブルは本当にE/Rは継承を行いません - 3つのJPA戦略のようにそれをシミュレートするかもしれませんが、彼はいくつかのトレードオフを受け入れなければなりません – giorgiga

関連する問題