1

facebookユーザーがまたはを介し​​て登録できるようにするアプリケーションに取り組んでおり、twitterこれらの Web サイトからユーザーの個人データを使用できるようにしたいと考えています。これが私がこれまでに思いついたものです：

ここに画像の説明を入力

このuserテーブルには、ユーザーの登録方法に関係なく存在する必要がある情報 ( first_name.

user_propertyテーブルはキャッシュとして機能し、または(フィールドで表される)key-valueに固有の情報を格納します。users' など、呼び出しまたはクエリの一部として個別に使用できるプロパティを保存し、 users'などの形式でシリアル化された他の呼び出しの結果を保存します。facebooktwitteroriginAPISQLfacebook idAPIJSONfacebook friends

その方法：

  • 私はテーブルに共通の情報を持っていuserます.1つのテーブルSELECTで、ユーザーに関する基本的な有用な情報を得ることができます.
  • と. facebook/twitter_ JOIN_ user_user_property
  • 正規化して保存するにはコストがかかりすぎる情報を取得できます (たとえば、人々の友人を保存するテーブルを作成し、友人ごとに 1 つのテーブル エントリを持つ)JOINと.useruser_property

で、今気になっているのが以下。

Q1: これはある程度持続可能なデータベース設計でしょうか?それとも、間違っていて何らかの問題が発生する可能性がありますか?

Q2: 頻繁に変更される情報 (友達/フォロワーのリストなど) を保存する場合、情報を最新の状態に保つにはどうすればよいですか? (そもそも DB に情報を保存しますか? もしそうなら、どのような基準/トリガーを使用しますか?いつ情報を再度取得するかを決定するために使用しますか)?

4

1 に答える 1

1

デザインには、EAVスキーマのほとんどの（悪い）属性（Entity-Attribute-Value）があります。その問題についてウィキペディアを探し、このサイトも見てください。

EAVでの最も持続不可能な設計上の決定は、（IMHO）であり、最初はこれが適切に拡張されているように見えます。しかし、データが大きくなるとすぐに、高速でコンクリートの壁にぶつかります。これは、 1人のユーザーのデータをロードするために、DBがランダムアクセスを使用して物理テーブルの大部分にアクセスする必要があるためです。1人のユーザーの行を隣接するページにまとめるようにDBを調整することは、データが大きくなり、頻繁に変更される場合、大変な作業です。user_property

于 2012-11-04T23:35:40.203 に答える