0

まず第一に、私はこの問題についてこれこれ、そしてこのトピックを読みました。私はそれを理解していると思いますが、私はほとんど関係を特定することしかできないので、私がそれを正しい方法で行っているかどうかはまだわかりません。基本的に正しい方向に向かっているかどうか知りたいです。

私は、とりわけユーザーがプロファイルを作成し(無料版と有料版を使用)、ニュースアイテムを投稿できるデータベースを作成しています。他のユーザーはこれらのアイテムに返信でき、反応は評価を受けることができます。これはウェブサイトの機能のほんの一部ですが、私が心配している部分です。私は以下を書き留めました(各行は2つのテーブル間のリンクを表します):

ユーザー:
1人のユーザーが1回追加情報を定義できます[識別、1:1]
1人のユーザーが1つの性的嗜好を持つことができます[識別、1:1]
1人のユーザーが1つの支払いステータスを持つことができます[識別、1:1]

1人のユーザーが5つの質問を定義できます[識別、1:n]
1人のユーザーが3つの追加情報行を定義できます[識別、1:n]
1人のユーザーが3つの関心を定義できます[識別、1:n]

ニュース:
1人のユーザーが複数のニュースアイテムを投稿できます[識別、1:n]
1つのニュースアイテムが複数のコメントを受け取ることができます[識別、1:n]
各コメントには1人の作成者(ユーザー)がいます[識別、1:1]
各コメントは1つの評価を受けることができます[識別、1:1]
各評価は、一度に1人のユーザーが設定できます[識別、1:1]

支払い:
1つのプロモーションは、すべてのユーザーまたは1人の特定のユーザーに適用できます[非識別、1:n]

上記の関係のほとんどすべてが識別されているので、私が問題を理解しているかどうか疑問に思います。

その上、私はstatus(とりわけ)ユーザーの支払い状況を保持するテーブル( promotions)と、可能なプロモーションを保持する別のテーブル()を使用します。promotionsテーブルをstatusまたはテーブルにリンクすることになっているのかどうかはわかりませんuser

誰かが疑問を解決するのを手伝ってくれますか?

4

1 に答える 1

0

特にあなたの身元確認と非身元確認の関係を考慮して、私があなたの質問に正確に答えるかどうかはわかりません。

あなたの言うことから、ステータステーブルとプロモーションテーブルは、私が参照テーブルと呼んでいるように見えます。これは、(エンティティアソシエーションモデルを使用して)1-n関係のユーザーテーブルにリンクできます。つまり、ユーザーテーブルにforeighキーがあります。ステータスIDとプロモーションIDを参照する別のID(これは履歴が必要ないことを意味します)-おそらくプロモーションに関して0-n

テーブルニュースは、ユーザーテーブル側のnカーディナリティを持つ同じ実現の王によってユーザーにリンクされます(つまり、ニューステーブル内の外部キーはユーザーIDを参照し、コメントテーブルの外部キーは外部キーを持つ新しいテーブルになりますコメントテーブル内のニュースIDを参照する

レーティングテーブルに関しては、あまり考えずに、ユーザーとコメントのnn関係の関連付けから来ていると言えます。結果:user_idとcomment_id外部キーが内部にあるテーブル...コメントの評価は、評価テーブルでの操作の結果ですが、より速くするために、評価が追加されるたびに評価テーブルにトリガーを設定できます。コメントテーブルのフィールドをプッシュできる新しい評価を計算するコメント

于 2013-03-26T13:17:49.940 に答える