Q&A
URLは https://teratail.com/help#about-markdown の[リンク]に修正してください。
サービス運営者からのお知らせの既読管理について質問があります。
実装したい機能としては、
「お知らせを公開し、ユーザーが未読の場合はNEWマーク、既読の場合はマークを削除」
というものですが、既読管理をデータベースで行う場合どのような方法がありますでしょうか。
構築の参考として下記サイトが見つかりました。
MySQL – お知らせなどの既読管理についてメモ
・ユーザーテーブルの作成(PK:userid)
・お知らせテーブルの作成(PK;infoid)
・useridとinfoidが入る、関連付け（既読判別）テーブルの作成
確かに上記の形では実装可能と思いましたが、ユーザーが増えていくと関連付けテーブルのuserid（既読判別）の長さ上限に達してしまい、機能しなくなるのでは？と思いました。
（普段はデザインメインなため知識不足でしたら申し訳ありません。。）
皆様のご意見をお聞かせください。
ご指摘ありがとうございます。修正いたしました。
> ユーザーが増えていくと関連付けテーブルのuserid（既読判別）の長さ上限に達してしまい、機能しなくなるのでは？と思いました。
・「関連付けテーブル」は notices_users テーブルを指していますか？
・「userid（既読判別）の長さ上限」とは具体的に何ですか？（notices_users テーブルのレコード数の上限？ userid の数値桁数？）
ありがとうございます。
いただいたご指摘で気づきました。。
notices_usersテーブルに対して、
「お知らせ毎にお知らせ関連付けレコードを追加して、useridに読んだユーザーのidを格納していく」
ではなく
「読まれる毎にお知らせ関連付けレコードを追加して、notice_idに読まれたお知らせid、useridに読んだユーザーidを格納」
という形でお間違い無いでしょうか？
前者の形で認識していたので、格納するuseridに桁数の問題があると思っていました。
ただ、後者のレコード追加の形では、例えば会員が数万人になると1回のお知らせで数万レコードが追加される事になりますが、この部分は特に問題は無さそうでしょうか？
よろしくお願いいたします。
回答3件
0
新しいことをすることにはリスクがあるもので、安易に勧めたいわけではありません。
まあ、質問者さんの興味次第です。
mts10806の回答でコメントしたことを再掲します。
量が気になる場合は、基本的に期限を切れる形にすると思います。
m6uさんのおっしゃるとおり、別テーブルに追い出すというのも方法の1つです。
最近では、(データベースに依存しますが)パーティション付きのテーブルを作れるものも多いはずなので、それで運用するのが一般的かと思います。これを使うと、例えば年ごとや月ごとのテーブルを内包する、親玉テーブルを作ることができ、ユーザーからは親玉テーブルだけを見てもらい、管理側は年ごとや月ごとのテーブルを扱うことで、簡単に取り外しが出来るようになりますし、インデックスの構築速度も速くなります。
MySQLを想定しているのではあれば、↓とかですね。
MySQL パーティショニングまとめ -Qiita-
追記1:
年ごととか、月ごととかのパーティションは、実際にその月や年になる前に、DDLを実行して作る必要があります。この手間がある分実装・運用コストが多少かかります。
投稿2019/02/27 01:53
編集2019/02/27 02:12
総合スコア343
0
確かに上記の形では実装可能と思いましたが、ユーザーが増えていくと関連付けテーブルのuserid（既読判別）の長さ上限に達してしまい、機能しなくなるのでは？と思いました。
（普段はデザインメインなため知識不足でしたら申し訳ありません。。）
お知らせって恒久的に残しておくものなのでしょうか。
期間を設けておいてその期間を過ぎたら削除してしまってもいいように思います。
投稿2019/02/27 00:17
総合スコア80850
古いお知らせを別テーブルに追い出してビューを組んだりとかもあるかな。
（恒久的に残すのが前提だけど、普段は直近の分しか利用しない場合など。）
それもありですね。アクティブなものと非アクティブなものが混ざってるのもそれはそれで非効率ですし。
SNSサービスを対応したときに、退会ユーザーは別テーブルに移すとかやったことあります。それと同じような感覚ですね。
ご意見ありがとうございます！
頂いた内容について参考にさせていただきます。
量が気になる場合は、基本的に期限を切れる形にすると思います。
m6uさんのおっしゃるとおり、別テーブルに追い出すというのも方法の1つです。
最近では、(データベースに依存しますが)パーティション付きのテーブルを作れるものも多いはずなので、それで運用するのが一般的かと思います。これを使うと、例えば年ごとや月ごとのテーブルを内包する、親玉テーブルを作ることができ、ユーザーからは親玉テーブルだけを見てもらい、管理側は年ごとや月ごとのテーブルを扱うことで、簡単に取り外しが出来るようになりますし、インデックスの構築速度も速くなります。
wwbQzhMkhhgEmhUさん
私そこまで言及してないので別回答にされたほうが質問者さんや他の方にも伝わると思います。
ちょっとニュアンス違うかもですが、パズドラというゲームアプリはお知らせ配信後60日経過したら既読管理しないようになりましたね。既読管理にかかる負荷(コスト)だけが要因ではないかもしれませんが。
tabuuさん
その前は365日とかでしたっけ。長すぎてみんな長期間放置したままにしてたからでしょうね。私は60日になったあとも結構未読放置してますけど・・・
0
ベストアンサー
notices_usersテーブルに対して、
「お知らせ毎にお知らせ関連付けレコードを追加して、useridに読んだユーザーのidを格納していく」
ではなく
「読まれる毎にお知らせ関連付けレコードを追加して、notice_idに読まれたお知らせid、useridに読んだユーザーidを格納」
という形でお間違い無いでしょうか？
はい。
ただ、後者のレコード追加の形では、例えば会員が数万人になると1回のお知らせで数万レコードが追加される事になりますが、この部分は特に問題は無さそうでしょうか？
問題ないかどうかは、お知らせの頻度、サーバーの性能、インフラ環境などに左右されるので一概には言えません。
投稿2019/02/26 23:46
総合スコア6500
ありがとうございます。
システムの設計については問題が無い、
ただし、相当なレコード数になる事が予測できるため、実装にはサーバー、インフラ環境を考慮する必要がある、という事ですね。
懸念していた部分が解消されましたので、後ほどBAさせていただきます。
ご丁寧にありがとうございました！
あなたの回答
tips
プレビュー
