5

今月、2つの異なる作業で同じ問題が発生しました。

Version 1: User 1 & User 2 are friends
Version 2: Axis 1 & Axis 2 when graphed should have the quadrants colored...

問題は、RDBMSを使用して、この情報を保存および照会するための洗練された方法が見当たらないことです。

2つの明白なアプローチがあります：

アプローチ1：

store the information twice (i.e. two db rows rows per relationship):
u1, u2, true 
u2, u1, true
u..n, u..i, true
u..i, u..n, true

have rules to always look for the inverse on updates: 
on read, no management needed
on create, create inverse
on delete, delete inverse
on update, update inverse

Advantage:    management logic is always the same.
Disadvantage: possibility of race conditions, extra storage (which is admittedly cheap, but feels wrong)

アプローチ2：

store the information once (i.e. one db row per relationship)
u1, u2, true
u..n, u..i, true

have rules to check for corollaries:
on read, if u1, u2 fails, check for u2, u1 
on create u1, u2: check for u2, u1, if it doesn't exist, create u1, u2
on delete, no management needed
on update, optionally redo same check as create

Advantage: Only store once
Disadvantage: Management requires different set of cleanup depending on the operation

「f（x、y）を使用するキー」の線に沿った3番目のアプローチがあるかどうか疑問に思います。ここで、f（x、y）はすべてのx、yの組み合わせに対して一意であり、f（x、y）=== f（y、x）」

私の腸は、これらの要件を満たすことができるビット単位の演算のいくつかの組み合わせが必要であると私に言います。2列のようなもの：

key1 = x && y key2 = x + y

数学科でより多くの時間を過ごし、社会学部でより少ない時間を過ごした人々が、これの可能性または不可能性の証拠を見て、迅速に「[You moron、]その簡単に証明された（im）可能です。このリンクを参照してください」（名前の呼び出しはオプション）

他のエレガントなアプローチも大歓迎です。

ありがとう

4

5 に答える 5

7

追加の制約を追加して、2番目のアプローチを使用する方法もあります。それを確認してくださいu1 < u2：

CREATE TABLE User
( Name VARCHAR(10) NOT NULL
, PRIMARY KEY (Name)
) ;

CREATE TABLE MutualFriendship
( u1 VARCHAR(10) NOT NULL
, u2 VARCHAR(10) NOT NULL
, PRIMARY KEY (u1, u2)
, FOREIGN KEY (u1) 
    REFERENCES User(Name)
, FOREIGN KEY (u2) 
    REFERENCES User(Name)
, CHECK (u1 < u2) 
) ;

読み取り、作成、挿入、または更新のルールでは、を使用する必要があり(LEAST(u1,u2), GREATEST(u1,u2))ます。

于 2012-01-10T20:31:48.997 に答える
2

SQL では、最初のアプローチをサポートする制約を簡単に実装できます。

CREATE TABLE MutualFriendship
(u1 VARCHAR(10) NOT NULL,
 u2 VARCHAR(10) NOT NULL,
 PRIMARY KEY (u1,u2),
 FOREIGN KEY (u2,u1) REFERENCES MutualFriendship (u1,u2));

INSERT INTO MutualFriendship VALUES
('Alice','Bob'),
('Bob','Alice');
于 2012-01-10T20:09:06.930 に答える
1

興味のある人のために、私はいくつかのビット演算を試してみたところ、次のことがf（x、y）の基準を満たしているように見えることがわかりました。

#Python, returns 3 tuple
def get_hash(x, y):
  return (x & y, x | y, x * y)

しかし、それを証明することはできません。

于 2012-01-10T21:17:11.013 に答える
0

「x は y の友達です」。

(x,y) ペアのテーブルを定義し、標準形式 (x<y など) を適用します。これにより、データベースに (p,q) と (q,p) の両方を含めることができなくなり、「一度だけ保存」されます。

SELECT x,y FROM FRIENDS UNION SELECT x as y, y as x FROM FRIENDS としてビューを作成します。

ベーステーブルに対して更新を行い（欠点：更新者は強制された正規形式を認識している必要があります）、ビューに対してクエリを実行します。

于 2012-01-10T23:57:16.717 に答える
-2

友達の数を 1 に制限しているようです。この場合は、u1,u2 u2,u1 u3,null u4,u5 u5,u4 のようなものを使用します。

u3 には友達がいません。

于 2012-01-10T19:20:25.990 に答える