0

ユーザーが自分のtwitter/facebook / foursquareアカウントで順番にログインし、フォローしている人のすべてのIDとその他の詳細を取得する（または友達としてリストに追加する）アプリケーションを作成しています。

私はこれらの質問に言及しました：

しかし、唯一のことは、上記の設計は「友情」モデルに焦点を合わせているのに対し、私は「フォロー」モデルに基づいてシステムを構築したいと考えています。
「友情」モデルでは、両方のユーザーがお互いを追加/確認しますが、「フォロー」モデルでは、1人のユーザーが確認なしで別のユーザーをフォローできます。

1つのテーブルにアプリのすべてのユーザーを格納し、他のテーブルに他の情報とともにフォローするすべてのユーザーを格納する設計を進めることもできますが、データベース設計があまり得意ではないため、シナリオが心配です。たくさんの行を複製してしまうとき。
例えば：

  • キャシーが何らかのネットワークでアナをフォローし、スティーブが他のネットワークでアナをフォローしている場合、私はアナの2つの行を持ち、これら2人のユーザーとの関係を示しています。これでいいですか？
  • 異なるネットワーク上で、アナとスティーブがお互いをフォローしている場合はどうなりますか？この関係に2つの行があることは避けられますか？
  • 一部のネットワークでは、スティーブはキャシーをフォローしています。これも、関係のために1つの行があります。これで大丈夫ですか？
  • Anaは複数のソーシャルネットワーク（twitter + facebook）でKathyの友達である可能性が高く、同じ人物Anaのこれら2つのネットワークの異なる情報を格納するために2つの行が必要になります。これでいいですか？

私はデータベース設計に関してはプロではなく、通常はデータベース設計者から設計されていますが、今回は私の個人的なアプリなので、何が良いのか、何が悪いのかがわかりません。

このシステムは、さまざまなユーザーが複数のソーシャルネットワークアカウントを追加することになるため、かなり大きくなる可能性があります。最初はLAMPを使用しますが、基本的には、データベースの設計が不適切になると複雑さが増す可能性があることを懸念しています。

スキーマに関する提案やアイデアは大歓迎です。
さらに情報が必要な場合はコメントしてください。

ありがとう！

4

2 に答える 2

1

データベースを正規化する場合は、関係ごとに個別の行が必要になります。すべての関係を保存した場合、たとえば、フォロワーIDをfollowerIDというフィールドに入力すると、そのレコードが1人のフォロワーに基づいて削除されると、すべてのフォロワーが削除されます。そうです、複数のレコードを使用することをお勧めします。

また、Follow_Relationshipsのように、followedとfollowerの主キー、およびその他の必要な関連情報を使用して、関係テーブルを設定することもできます。そうすれば、2つのテーブルで結合を実行できます。

これがお役に立てば幸いです。

于 2012-12-11T12:54:14.927 に答える
1

ソーシャルネットワークの数は限られているので、単一の関係のフラグとして異なるネットワークの関係を持つことはそれほど無駄ではありません。

たとえば、SteveとAnaが任意のネットワークで接続されている場合、関係は、異なるフォロー/友達関係を示す追加の列を持つ単一の行で表すことができます。ユーザー数が限られている場合は、設計の効率とのトレードオフを伴う使いやすさのために、これは許容できる場合があります。

大規模なデータベースの場合、適切な関係が推奨され、各ユーザーとの関係ごとに個別のレコードが必要になると思います。2人のユーザーが互いにフォローし合うシナリオがある場合、2人のユーザー間の単一のレコードに対して「isReciprocal」フラグを設定できると思います。

User1|User2|isReciprocal
Steve|Kathy|1

isReciprocal = 1の場合、それらは互いにフォローし、0の場合、SteveはKathyをフォローしますが、KathyはSteveをフォローしません。

関係が変更された場合（スティーブがキャシーのフォローを解除し、キャシーがスティーブのフォローを開始します）、キャシーがユーザー1、スティーブがユーザー2になるように関係を変更できます。それが明確であることを願っています。

最終的には、設計は規模の問題ですが。たとえば、ユーザー数が10000人未満で、更新の頻度が低い場合、一部の非常に非効率的な設計は完全に問題ありません。常に更新される数万/数十万のレコードと関係を取得している場合は、設計をより効率的にすることをお勧めします。

多くの場合、小さくて高速なソリューションは過度に設計されている可能性があります。このような状況では、結果として得られる使いやすさのために、正規化されていないデータは許容できると思います。

于 2012-12-11T12:58:40.827 に答える