18

私はまだこれに出くわしたことがないのはおかしいです!

ユーザーが互いに「友達」になれるシステム (ソーシャルネットワーキング) に取り組み始めるまで、1 つのテーブルで「多対多」の関係を持つことができるとは思いもしませんでした。

標準のルックアップ テーブルは、少なくとも私が使い慣れている方法では、ここでは適切ではありません。シンプルにしましょう:

ユーザーテーブルには「id」と「name」列があります。

User_relationship テーブルには「uid1」と「uid2」があり、「友人」、「芽」、「仲間」、または「それ以外」のユーザーを表します。

ここでの問題が何であるかはすぐに明らかになります.uid1とuid2は同じテーブルの同じ列からの同じデータ型です。つまり、一意のキーに欠陥があります。

例: uid1 = 1 uid2 = 2

以下と同じです:

uid1 = 2 uid2 = 1

したがって、クエリが間違って実行された場合、2 つのレコードまたは 0 レコードが返される可能性があります。

テーブルを適切に設計するという精神から、既存の値を確認するためにテーブル全体を 2 回スキャンする必要はありません。

これを処理するためのある種のトリックはありますか?これは私が思いもよらなかった設計上の問題であり、それを機能させるための簡単なトリックがあることを知っているので、私はイライラします。

あなたが尋ねる前に、私はまだ何も試していません.物事を関連付ける私のお気に入りの方法(ルックアップテーブル)は、ここでの私のニーズには不十分であり、助けが必要です-SOまたはGoogleで何も見つかりません. :(

前もって感謝します。

4

4 に答える 4

10

つまり、一意のキーに欠陥が生じます。

uid1 = 1 uid2 = 2

以下と同じです:

uid1 = 2 uid2 = 1

いいえ、そうではありません。

たとえば、Facebook では、「友達」になりたいというリクエストを送信した多くの顧客がいますが、それを受け入れたことはありません... ただの知り合いだからです。

同じように、何人かの人を親友としてマークしたかもしれませんが、彼らは往復しませんでした。あるいは、私はいくつかを無視していますが、そうではありません。

(uid1, uid2)基本的に、タプルには単なる ID よりも多くの情報があります。

uid1 < uid2たとえば、テーブルに制約を追加することを決定する前に、このような状況に対処する必要がないことを確認してください。

于 2013-06-15T22:28:05.647 に答える
2

これはそれほど珍しいことではありません。

通常、主キーを構成する 2 つのテーブルの 2 つの列 (それぞれが ID) で構成される多対多の関係のように、テーブルが存在することで行われます。

あなたが述べたように、userId1とuserId2。必要に応じて、関係に属性を追加できます (友情の分類など)。

ユーザー 1 がユーザー 2 と友達になった場合、通常は (1,2) と (2,1) の 2 つの挿入があります。

フレンド解除と同じようなことで、2 つの削除が必要です。

ユーザーが自分自身を友人として持つことになる可能性があり、それはシステムの実際の動作にとって重要な場合があります. ユーザーが自分の友達の写真しか表示できない場合、そのユーザーが自分自身の友達でない場合、システムによっては自分の写真を見ることができない場合があります。

これは、アプリケーションがデータベース上でどのように作成されるかに大きく依存します。

于 2013-06-15T22:30:45.330 に答える
1

私は他の人が言ったことに同意します.関係のために2つのインサートを持つことは悪い考えではありません(1:2と2:1). これは実際、現代のソーシャル ネットワークで一般的に見られる機能の一部を拡張するのに役立ちます。私が考えることができるいくつかの実用的な使用例は、関係またはその他の属性の記述です。個人は友達のままですが、お互いに異なる設定を維持しています。1:2 の関係では、Bob は Joe の最新情報をフォローしており、彼を親友リストに入れています (bff 列を追加)。一方、2:1 の場合、Joe は Bob を bff リストに入れておらず、彼の投稿をフォローする気もありません (次の列)。 .

于 2013-10-28T20:44:53.820 に答える