• 解決済 notenotennoote

    (@notenotennoote)


    「Aさんが記事を投稿しました」などの通知をBさんに対して行いたいのですが、【1】と【2】ではどちらのプランよろしいでしょうか?

    【1】Bさんのカスタムフィールドに対して下記更新を行うプラン

    
    $user_id = '20'; // Bさんのuser_id
    $current_notifictions=get_user_meta($user_id,'notifications',true);
    $new_notifications=[
    	'type'     => 'posted', // 通知の種類 
    	'actor_id' => '10' // Aさんのuser_id
    ];
    $update_notifications = array_merge($new_notifictions,$current_notifictions);
    update_user_meta($user_id,$update_notifications);
    

    【2】投稿タイプnotificationを投稿するプラン

    
    $value=[
    	'post_type'    => 'notification',
    	'post_author'  => '20', // Bさんのuser_id
    	'post_name'    => substr(str_shuffle('123abcABC'), 0, 3);
    	'post_title'   => '',
    	'post_content' => '',
    	'post_status'  => 'publish',
    ];
    $insert_id=wp_insert_post($value);
    update_post_meta($insert_id,'notification_type','posted'); // 通知の種類 
    update_post_meta($insert_id,'actor_id','10'); // Aさんのuser_id
    

    いずれもBさんに表示するときは、notification_typeactor_idを元にして「Aさんが記事を投稿しました」というテキストを生成しようと思っています。(翻訳などしたいため、テキストは直接入れておかず表示のときに生成する。)

    データベースの量、管理のしやすさ、表示の速度など、多面的なご意見を頂けましたら幸いです。

    また、「【3】の方がいいよ」など他のプラン等ございましたらぜひ宜しくお願い致します。

6件の返信を表示中 - 1 - 6件目 (全6件中)
  • こんにちは

    正直なところ、前提や要件の情報が少なすぎて、何が最適なのか、自分ならどうするのかなどの想定ができかねる状態です。

    通知はどのような目的で必要なのか、何件ぐらいの通知を表示することを想定しているのか、永遠に蓄積していくのか、同じ投稿を更新したときも通知するのか、通知はいつ表示されるのか、A さんと B さんの紐づけをどこで定義しているのか、などなど。

    私ならAさんの投稿の post_meta に情報を持たせる気もしますが、前提がわからないので判断が難しいです。

    トピック投稿者 notenotennoote

    (@notenotennoote)

    こんにちは

    ご返信ありがとうございます。なるほど、要件ですか。実はTwitterを作ろうとしています。なので通知内容は一緒で、ただあまりデータベースを圧迫するようならば1か月間だけとか、または100件までのような制限を設けようかと思っています。なので具体的な要件は決まっておらず、Twitterのようなものならばどのような設計がいいのか、という質問です。
    ・目的はTwitterと同様で、フォローやいいねや記事の投稿(ツイート)を通知する
    ・件数は未定
    ・期間も未定
    といった感じで、どうしようか考えている状況です。

    といった感じで、どうしようか考えている状況です。

    でしたら、今は何が良いかを知るのではなく、どのようなやり方があるのかという選択肢を並べたいということでしょうか?

    想定される件数が未定なのではどこまで考えたらいいのか分からないので、それもちょっと難しいですが・・・

    件数が多いなら、私なら独自のテーブルを作るかもしれません。
    テーブルの構造と SQL を自分でコントロールしたいですし。
    しかし、月に100万件のお知らせが生成されるのなら、MySQL のような RDBMS にそのデータを保持するのはナンセンスかもしれませんん。すごいスペックのサーバーを用意したりできるのであれば、それもいいのかもしれません。

    トピック投稿者 notenotennoote

    (@notenotennoote)

    少ない情報の中でお付き合いいただき誠にありがとうございます。

    たしかに選択肢を把握したかったかもしれません。
    そしてなるほど、通知のデータ管理のやり方としては
    【1】Bさんのカスタムフィールドに対して更新を行うプラン
    【2】投稿タイプnotificationを投稿するプラン
    【3】教えて頂いた、独自のテーブルを作って更新するプラン
    がある感じですね。

    実際どの通知プラグインも【3】でした。

    疑問なのですけど、【3】より【1】の方が、取得が早くないでしょうか?

    というのは、【1】は一人のカスタムフィールドを覗くだけなのに対して、【3】は独自テーブルからいくつかのカラム(ロウ?よくわかりませんが…)をつなげたりして取得しないといけないので、なら【1】の方がいいのではないかと思っています。

    もちろんどのプラグインでも【3】なので、やはり @munyagu さんの仰る通り【3】がベストなのだとは思いますが、それはなぜなのでしょうか?

    3 より 1 の方が速くなというか、要件によってどちらが良いかは変わります。

    wp_postmata には日付項目がありません。
    ですので、データを取得した場合にどのような順番で取得できるかは、MySQL まかせです。
    直近1週間の通知を検索して取得することもできません。

    通知を wp_postmata の 1 レコードに、日付項目を含むシリアライズした配列データで保持すれば、上記の要件は満たせます。
    しかし、必要なのは 1 週間分 10 件だけなのに、一旦 1 年分 5,000 件取ってこないといけないかもしれません。
    パフォーマンス的には好ましくないでしょう。
    しかし、常に 10 件しか保持しなくて順番はどうでもいいなら、wp_postmata に持たせてもいいかもしれません。

    トピック投稿者 notenotennoote

    (@notenotennoote)

    ご返信ありがとうございます。

    すると【3】のような独自テーブルを作るスキルがないことを前提に考えると、【1】の保存形式を「>日付項目を含むシリアライズした配列データで保持」とし、あとは件数を100件まで、のように限定するのがよさそうですね。わざわざ投稿する【2】だと1件ごとのスラッグとか無駄な情報が多いですもんね。ぼんやり見えてきました。

6件の返信を表示中 - 1 - 6件目 (全6件中)
  • トピック「通知システムとデータベースについて」には新たに返信することはできません。