ダウンロードサイトのようなデータベースを設計する必要があります。ユーザー、各ユーザーがダウンロードしたプログラムを追跡し、ユーザーがそのプログラムを評価+コメントできるようにしたい。このデータベースから必要なもの-プログラムの平均評価を取得し、プログラムのすべてのコメントを取得し、正確にどのプログラムを知っているか誰がダウンロードしたか（各プログラムが何回ダウンロードされたかは気にしないが、各ユーザーがどのプログラムをダウンロードしたかを知りたい）、多分各プログラムのコメント数とそれについてのこと（これは非常に小さなプロジェクトですシンプルにしておきたい個人的な使用）私はこれらのエンティティを思いつきます-
ユーザー（uid、unameなど）
プログラム（pid、pname）
そして、次の関係-
UserDownloadedProgram（uid、pid、timestamp）
UserCommentedOnProgram（uid、pid、commentText、timestamp）
UserRatedProgram（uid、pid、rating）
私がこのように選んだ理由-関係（ユーザーのダウンロード、ユーザーのコメント、レート）は多対多です。ユーザーは多くのプログラムをダウンロードし、プログラムは多くのユーザーによってダウンロードされます。コメントについても同じことが言えます（ユーザーが多くのプログラムにコメントし、プログラムが多くのユーザーによってコメントまたは評価されます）。私の知る限り、ベストプラクティスは、1対多の3番目のテーブル（リレーションシップテーブル）を作成することです。。このデザインでは、平均的な評価とコメントの取得は、結合クエリなどによって行われると思います。私はデータベース設計の初心者ですが、ベストプラクティスを順守しようとしています。この設計は多かれ少なかれ大丈夫ですか、それとも何かを見落としていますか？
私は間違いなく他の可能性を考えることができます-多分コメントや評価はそれ自体がエンティティ（テーブル）であり、関係は3つのエンティティ間にあります。そのメリット/デメリットが何であるかはよくわかりません。コメントや評価はあまり気にしないので、適切な場所に表示して維持したいだけです（必要に応じて削除してください）。彼ら自身が実体になったほうがいいかどうかわかりますか？
何かご意見は？