web-dev-qa-db-ja.com

ブログ投稿のいいね/シェア/コメントを追跡するデータベースモデル

私の目標は、ソーシャルネットワークのアクティビティに基づいて、さまざまなブログサイトで人気のある投稿を常に追跡することです。目標は、単に現在最も人気のあるものを取得することではなく、同じブログの他の投稿と比較して人気のある投稿を見つけることです。たとえば、技術系のブログ、スポーツ系のブログ、ゴシップ系のブログをフォローしています。ハイテクブログは他の2つのブログよりも読者数が多いので、ハイテクブログのすべての投稿は、他の2つのブログのビューよりも常に多く表示されます。たとえば、平均的なテクノロジーブログの投稿には500件のFacebookのいいねがあり、他の2つの投稿には1件の投稿あたり平均で50件のいいねが表示されます。それから、200 fbのいいね！と300のゴシップブログ投稿を含むスポーツブログ投稿があり、今日のテクノロジーブログ投稿が500いいねを持っている場合、スポーツとゴシップブログ投稿を強調したい（平均よりもいいねvsテクノロジーブログのほうが多い＃いいね！でもブログの平均値）

私が考えているアプローチは、各ブログ投稿のデータベースにエントリを作成することです。 x分ごと（たとえば15分ごと）に、すべてのソーシャルネットワーク（facebook、Twitter、google +、linkeIn）でエントリがどのくらいのいいね/共有/コメントを受け取ったかを確認します。したがって、時間の経過とともに、各ブログ投稿のいいね！の履歴、つまり

   post 1234 

        after 15 min: 10 fb likes, 4 tweets, 6 g+
        after 30 min: 15 fb likes, 15 tweets, 10 g+
        ...
        ...
        after 48 hours: 200 fb likes, 25 tweets, 15 g+

各ブログ投稿に対してこのような履歴を保持することにより、任意の時間間隔でのいいね/シェア/ツイートの平均数を知ることができます。たとえば、投稿から48時間後のすべてのブログ投稿のfbのいいね！の平均数は50であり、特定の投稿には200あります。これを人気のある投稿としてマークし、機能/強調表示できます。設計における考慮事項は、特定の時間フレームの値（いいね/シェア）を簡単にクエリできるようにすることです。つまり、fbは30分後にいいね！または24時間後につぶやいて、比較対象の平均を計算します（または平均はそれ自身のテーブルに保存されますか？）

このアプローチに欠陥がある場合、または改善が見込める場合はお知らせください。ただし、これは私の主な質問ではありません。私の主な質問は、この情報を保存するためのデータベーススキームはどのように見えるべきかということです。

上記のアプローチが取られていると仮定して、いいねを保存するためのデータベーススキーマがどのように見えるかを理解しようとしています。私はデータベースに慣れていないので、いくつかの基本的な読み物を行う際に、3NFデータベースを作成することをお勧めします。私は次の可能なスキーマを考え出しました。

スキーマ1

DB Popular Posts

  Table: Post
    post_id ( primary key(pk) )
    url
    title 

  Table: Social Activity
    activity_id (pk)
    url (fk)
    type (i.e. facebook,Twitter,g+)
    value
    timestamp

これは私の最初の本能でした（私の非常に限られたデータベースの知識に基づいています）。私が理解している限り、このスキーマは3NFでしょうか？私は同様のデータベースモデルのデザインを検索し、この質問をstackoverflowで見つけました https://stackoverflow.com/questions/11216080/data-structure-for-storing-height-and-weight-etc-over- time-for-multiple-users 。その質問のシナリオは似ています（時間外のユーザーの体重/身長の記録）。その質問に対して受け入れられた回答を取り、それを私のモデルに適用すると、次のような結果になります。

スキーマ2（上記と同じですが、ソーシャルアクティビティを2つのテーブルに分類します）

DB Popular Posts

  Table: Post
    post_id (pk)
    url
    title 

  Table: Social Measurement
    measurement_id (pk)
    post_id (fk)
    timestamp

  Table: Social stat
    stat_id (pk)
    measurement_id (fk)
    type (i.e. facebook,Twitter,g+)
    value

スキーマ2で見る利点は、特定の時間のすべての値にアクセスする可能性が高いことです。つまり、投稿が公開されてから30分後に測定を行うと、fbのいいね、fbの共有、fbのコメントの数を同時にチェックします。ツイート、g +、linkedIn。したがって、このスキーマを使用すると、特定の時間に対応するMeasurement_idのすべての統計情報、つまり時刻xの投稿1234のすべてのソーシャル統計情報を取得する方が簡単な場合があります。

もう1つの考えは、fbのいいねの数をつぶやきやg +の共有の数と比較するのは意味がないため、各ソーシャル測定値を独自のテーブルに分けるのは理にかなっているのではないでしょうか。

スキーマ3

DB Popular Posts

  Table: Post
    post_id (pk)
    url
    title 

  Table: fb_likes
    fb_like_id (pk)
    post_id (fk)
    timestamp
    value

  Table: fb_shares
    fb_shares_id (pk)
    post_id (fk)
    timestamp
    value

  Table: tweets
    tweets__id (pk)
    post_id (fk)
    timestamp
    value

  Table: google_plus
    google_plus_id (pk)
    post_id (fk)
    timestamp
    value

ご覧のように、私は一般的にどのようなアプローチを取るか迷っています。

一般的な解決策が必要なこの典型的なタイプのデータベースの問題（時間の経過に伴う測定値の保存、つまり温度統計）は確かです。このためのデザインパターン/モデルはありますか、名前はありますか？ 「データベースの定期的なデータ収集」または「データベースの経時変化」を検索してみましたが、具体的なものは見つかりませんでした。

この問題のニーズを解決するための適切なモデルは何でしょうか？

web-developmentdatabasesqldatabase-designrelational-database
6
gage

だから、これを読んで、私は次の仕様を見ます：

  1. ブログの人気度を追跡したい。これは、48時間の期間での「いいね」の合計または何でも（リツイートなど）、「通常」のレベルと比較することで達成されます。

  2. 構成可能な定期的な間隔で、いいね、リツイートの現在の数を更新したい。

  3. いいね、リツイートなどの効果を互いに独立して計算できるようにする必要があります。

最も簡単な方法は、3番目のスキーマを使用することです。それでも、すべての統計を同時にまたは個別に収集できます。唯一の影響は、独立している場合のみです。現在のランキングが実際のランキングを反映していない時間枠が常に存在しますが、同時の場合、ランキングは最大で更新率だけ「真実」より遅れます。

とにかく、その後、各post_idに対して定期的にクエリを実行し、過去48時間のfbいいね指標+過去48時間のツイート指標などを計算し、それを使用してランキングを更新できます。

2
iheanyi

アプリケーションに尋ねたい質問に答えるには、ブログ、投稿、アクティビティの3つの情報を保存する必要があります。

ブログ全体ではなく、各ブログ内で投稿をランク付け/強調表示したいので、どの投稿がどのブログに属しているかを知る必要があるため、ブログは単に投稿のコンテナーです。投稿はかなり静的ですが、それぞれのブログやソーシャルアクティビティとは無関係です。ソーシャルアクティビティは非常に動的であり（時間の経過とともにベルカーブのように見える可能性があります）、ソーシャルアクティビティの発見が時間の経過とともに遮断される場合とそうでない場合があります。

これで、ブログ、投稿、アクティビティという3つのコアエンティティが残ります。スキーマは次のようになります。

blog          post          activity
----------    -----------   --------
blog_id (pk)  post_id (pk)  activity_id (pk)
url           blog_id (fk)  post_id (fk)           
title         url           facebook_likes
              title         Twitter_tweets
                            google_shares

これは、実際のソーシャルメディアアクティビティ自体の保存、つまりツイートのURLなどの保存、および各投稿のソーシャルアクティビティ検出の結果の保存には関心がないことを前提としています。今日、新しい投稿に対してこれを実行すると、アクティビティテーブルに結果が挿入されます。明日もう一度検出を実行すると、アクティビティテーブルの行は既に存在しているので、そのときの結果で更新します。

（機能クリープアラート：発見ごとに新しい行を保存すると、ソーシャルメディアのアクティビティが時間の経過とともにどのように進展するかについて、貴重な洞察を得ることができます。たとえば、どのメディアが投稿をすばやく取得し、どのメディアが遅れているかを確認できます。そしてプレゼンテーションを盛り上げる便利なグラフを作成できます。これを行うには、まったく同じものを格納する必要がありますが、検出が行われた日付/タイムスタンプも追加する必要があります。）

外部キーは、行を別のテーブルの行に接続します。たとえば、ブログには複数の投稿があり、投稿は単一のブログに属しています。これは1対多の関係です。1つのブログには多数の投稿があり、1つの投稿は1つだけのブログに属しています。ブログはblog_id 1を持つことができます。そのブログに属するすべての投稿のblog_idは1に設定されます。

技術的には、必要に応じてアクティビティテーブルを削除し、列を投稿テーブルに移動できます。私がそれらを別々に保つ理由は、それらが別個のエンティティであり、それが将来の変更のための扉を開いたままにしているからです。たとえば、タイムスタンプを簡単に追加し、時間とともに変化するものとしてアクティビティを保存できます。さらに、それをさらに分解して、実際の個々のソーシャルメディアアクション（ツイートなど）を格納する別のテーブル（アクションなど）を追加することもできます。

最適化として、必要に応じて、それぞれのエンティティ（つまり、テーブルと投稿）のメトリックを計算して保存できます。これは、ディスカバリーを実行した後のデータの読み取りに関して、主に懸念事項です。ユーザーが情報を読み取る回数に比べて、データベースの計算と更新はほとんど行われないことを覚えておいてください。つまり、非正規化と集計により、提示したいデータを生成するために必要なクエリの数が減ります。ユーザー。

0
kaared