私は、リレーショナルデータベースのレコードの関係をモデル化する最良の方法を決定しようとしています。それは古典的な友人の/モデルに従ってください:RDBMSのフレンズとフォロワーのモデリング
~~~~
ユーザーは多くの友人にゼロを持つことができます。
ユーザーは、0〜多数のフォロワーを持つことができます。
友だちとフォロワーは両方ともユーザー自身です。
~~~~~
これをモデル化する最良の方法は何ですか?
ありがとうございます!
私は、リレーショナルデータベースのレコードの関係をモデル化する最良の方法を決定しようとしています。それは古典的な友人の/モデルに従ってください:RDBMSのフレンズとフォロワーのモデリング
~~~~
ユーザーは多くの友人にゼロを持つことができます。
ユーザーは、0〜多数のフォロワーを持つことができます。
友だちとフォロワーは両方ともユーザー自身です。
~~~~~
これをモデル化する最良の方法は何ですか?
ありがとうございます!
ユーザー(ユーザーID、...)
スクリプション(購読者、出版社)
友情(FirstUser、SecondUser)
CREATE TABLE Users (
UserID int not null primary key,
...
)
CREATE TABLE Subscription (
Subscriber int not null references Users(UserID),
Publisher int not null references Users(UserID),
constraint ck_NotEqual check (Subscriber <> Publisher)
)
CREATE TABLE Friendship (
FirstUser int not null references Users(UserID),
SecondUser int not null references Users(UserID),
constraint ck_Order check (FirstUser < SecondUser) -- since friendship is reflective
)
Aが友人Bである場合、BもAの友人であるため、両方の関係を記録することも、1つだけ保持することもできます。このチェックの制約により、第1ユーザのIDは第2ユーザのIDよりも常に小さいので、友人関係をチェックする方法を常に知ることができ、ダイスは存在しません。 –
そして、この定義の下では、往復運動がない「追い越しの友」は「追従者」ですか?さもなければ、私は恐らくフレンドシップテーブルを非対称に保つでしょう.1つのエントリは、UserAがUserBをフレンドとして記録し、別のエントリはUserBがUserAをフレンドとして記録することを記録します。 –
@Jonathan:まだ受け入れられていない「友人招待状」を保存できる必要があることに同意します。恐らく、指向性である別のテーブル「招待状」は、招待の日付を含む(期限が切れる必要がある場合など)。受取人が受け入れると、それは「フレンドシップ」テーブルに移動する。 –
重要な質問:どのように友人が信者に関係していますか? つまり、私の友人も私の信者ですか? – deworde
私がフォロワーに従えば、私たちは友達になるのですか? – deworde