0

私はソーシャルネットワーキングサイトの私のバージョンになる予定のデータベースを構築しています。さて、Facebookのように友達関係を保存したいと思います。私はこれにMySQLを使用していることに言及する必要があります。

だから私はこのようなことをすることを考えています：

UserFriends
(
    UserFriendID SOME_DATA_TYPE NOT NULL AUTO_INCREMENT PRIMARY KEY,
    UserID BIGINT(20) UNSIGNED NOT NULL,
    FriendID BIGINT(20) UNSIGNED NOT NULL -- This is basically the same as UserID
)Engine=InnoDB;

今、私はこのテーブルの主キーに使用するある種のデータ型を探しています。これは、大量のレコードがあると予想し、ある種のインデックス付けであらゆる種類の検索を高速化することを望んでいるためです。私が記録で行うかもしれないこと。友達提案機能など。

私は提案を受け入れています。私の意見では、別のオプションですが、管理がはるかに難しいのは、ユーザーごとに個別のテーブルを動的に作成し、その中に友達を保存することです。ただし、これはコードごとに管理するのは悪夢のようなものです。

4

4 に答える 4

1

あなたがこのようなことをするなら

create table UserFriends
(
    UserFriendID SOME_DATA_TYPE NOT NULL AUTO_INCREMENT PRIMARY KEY,
    UserID BIGINT(20) UNSIGNED NOT NULL,
    FriendID BIGINT(20) UNSIGNED NOT NULL -- This is basically the same as UserID
) Engine=InnoDB;

そうすると、おそらく次のようなデータになってしまうでしょう。

UserFriendID  UserID  FriendID
--
1             100     201
2             100     201
3             201     100

それに関する問題は明白なはずです。

誰が誰と友達になったのかを知る必要がない場合は、このようなものの方が理にかなっています。（MySQLではなく標準SQL。）

create table UserFriends (
    UserID BIGINT(20) UNSIGNED NOT NULL,
    FriendID BIGINT(20) UNSIGNED NOT NULL,
    primary key (UserID, FriendID),
    check (UserID < FriendID),
    foreign key (UserID) references users (UserID),
    foreign key FriendID references users (UserID)
);

主キーの制約により、単一の「友情」に対して複数の同一の行がないことが保証されます。check（）制約は、単一の「友情」に対して、ID番号の順序のみが異なる2つの行がないことを保証します。

ただし、MySQLはcheck（）制約を強制しないため、UserIDがFriendIDよりも小さいことを確認するトリガーを作成する必要があります。

于 2012-10-08T18:46:08.640 に答える
0

同じパターンを使用するBIGINT(20)

疫病のようなユーザーごとのテーブルを避けてください:)

于 2012-10-08T18:38:30.880 に答える
0

INTを使用するだけです。パフォーマンスを最適化する方法はたくさんありますが、異常な主キーデータ型を選択することはその1つではありません。

ユーザーごとに1つのテーブルを作成しないでください。本当に多くのユーザーがいる場合は、後でボトルネックがどこにあるかがわかったときに、シャードキーでユーザーを分割できます。

于 2012-10-08T18:39:14.810 に答える
0

INTデータ型を満たすのに十分なレコードがあると予想される場合、MySQLは、特に推奨事項、マルチレベルの友人の友人などには適切なソリューションではありません。グラフデータベースの1つに適している可能性があります。 。Neo4jは、ソーシャルネットワーク用に特別に設計された良い例です。http://neo4j.orgそれをチェックしてください、良い代替案かもしれません。mysqlを取り除く必要はありません。おそらく、ハイブリッドアプローチになります。

于 2012-10-08T18:56:53.513 に答える