Laravel 5.5 でポイント機能の実装をする方法

Question

前提・実現したいこと

＜前提＞
プログラミング初心者です。
Laravelで大学口コミサイトを作っております。

＜実現したいこと＞
●大まかな流れ
①.ユーザーが大学に対して口コミを投稿する
②.管理者が口コミ内容を確認し、承認をした投稿に対して任意のポイントを付与する

＜実現するために行ったこと＞
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
①については実装済みです。
[ユーザーテーブル]と[口コミテーブル]は
[ユーザーテーブル] 1 対 多 [口コミテーブル]
でリレーションを紐付けています。

[口コミテーブル]と[大学テーブル]は
[口コミテーブル] 多 対 多 [大学テーブル]
でリレーションを紐付けています。※大学口コミテーブル＝中間テーブルも作ってます

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
②を実装するにあたり、管理者側が操作できるためのページが必要だと思いましたので、
Laravel-admin【公式ドキュメント】をインストールし、
口コミを一覧で表示することまではできました。

発生している問題

＜②を実装する上での問題点＞

（1）エンティティのリレーションがどのように組むのが良いか分からない

[ユーザーテーブル]
[口コミテーブル]
[ポイントテーブル]※未作成
これらの３つのエンティティと、中間テーブルなるものが必要なのかとは思っていますが不確実です・・・。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
（2）ポイントテーブルの属性(アトリビュート)が何が必要となるのか分からない

必要だと思われる[属性]としては、[ポイント数]は思いつくのですがそれ以外に必要と思われるのが何かわからない

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
（3）承認済みかどうか判定する属性が必要と思われるが、どのテーブルに作るべきものかが分からない

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
（4）中間テーブルが必要となる場合、Laravel-adminでの登録方法が分からない
Laravel-admin【公式ドキュメント：HasMany】では、hasManyの関係性のフォームは可能みたいだが、belongsToManyの関係性のフォームの作り方がわからない

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

今までは、どうにかネットの情報で実装進めれましたが、今回の実装に合う情報がなかなか見つけれませんでした。
また、今までの実装を置き換えて応用しようとも思いましたが、うまくできず3日も進まず困りましたので質問させていただきました。

初めての利用のため何かと説明が不十分かと思いますが、どなたかご教授いただけませんでしょうか。
何卒、宜しくお願い致します。

Answer 1

質問上での表記ゆれがあって、ちょっと曖昧でしたので、

口コミ・投稿・レビュー　→　口コミ　、　ポイント・評価点　→　ポイント

と解釈して回答してみます！
なかなかの長文になってしまったのですが、間違って解釈している部分があったら、すみません。。^^;

---

管理者が口コミ内容を確認し、承認をした投稿に対して任意のポイントを付与する

これは、

■管理者が口コミ内容を確認し、承認
■承認された口コミに対して任意のポイントを付与する

こう分けて考えてみます。

■管理者が口コミ内容を確認し、承認

口コミ1つに対し、１つの承認フラグがあればいいのだと思いますので、
[口コミテーブル]に、承認フラグのカラムを追加するのが一番簡単な方法ですよね。

別テーブルにしたければ、[口コミ承認テーブル]のようなものを作ることになります。
必要なカラムは、
・「どの口コミ」を
・「いつ（承認処理された日）」
・「承認したか（承認フラグ）」
（・複数管理者であれば、「どの管理者」が）

くらいでしょうか。
[口コミテーブル]と[口コミ承認テーブル]は1対1の関係で、
口コミデータ無しに、口コミ承認テーブルのデータは存在しないことになります。

わざわざこの数カラムだけを別テーブルにしなくても。。と思う人もいると思いますが、
[口コミテーブル]は、ユーザーが更新するもの
口コミに関する承認フラグは、[口コミ承認テーブル]で「管理者」が更新するもの
と用途で、テーブルごと分けておくのは、
「こっちでは更新するつもりのなかったデータを更新しちゃった・・」なんていう不具合を避ける方法として、古めかしい方法かもしれませんが、ありだと思います。

■承認された投稿に対して任意のポイントを付与する

通常の「口コミサイト」を考えると、
口コミ作成者以外の他ユーザーがポイントを付与（評価する）のかと思いましたが、
文章からは「管理者」がポイントを付与する、とも読み取れます・・・

どちらか分からないので、両方書いてみます。

・管理者が付与する場合
1つの口コミに対し、ポイントを1回付与という話になるかと思います。
であれば、承認フラグと同じように扱えばいいですね。

カラムも似たような感じで。

・「どの口コミ」に
・「いつ（ポイント付与された日）」
・「何ポイント付与した（ポイント数）」
（・複数管理者であれば、「どの管理者」が）

承認フラグと同じで、別テーブルに分けるのでもいいと思います。

ただ、あんまりテーブルが増えると管理が煩雑になってしまいますので、
今回の場合は、管理者が登録する内容として、「承認フラグ」とまとめて、[口コミ管理テーブル]のような感じで、１つにしてしまってもいいかもしれません。

まとめるならカラムは両方分・・
・「どの口コミ」を
・「いつ（承認された日）」
・「承認したか（承認フラグ）」
（・複数管理者であれば、「承認処理したのはどの管理者」）
・「いつ（ポイント付与された日）」
・「何ポイント付与した（ポイント数）」
（・複数管理者であれば、「ポイント付与したのはどの管理者」）

[口コミ承認テーブル]の時ど同様、[口コミテーブル]と[口コミ管理テーブル]の関係は、1対1です。
口コミデータ無しに、口コミ管理テーブルのデータは存在しないです。

（この場合、管理者用の口コミ一覧画面の「評価点（平均）」は、「ポイント」とは異なるもの、ということなるのかなぁ・・と解釈の迷子・・）

・他ユーザーが付与する場合
1つの口コミに対して複数ユーザがポイント付与すると思いますので、[口コミポイントテーブル]が必要になります。

必要なカラムは管理者が付与する場合とそう変わらないかと思います。
・「どの口コミ」に
・「いつ（ポイント付与された日）」
・「どのユーザー」が
・「何ポイント付与した（ポイント数）」

[口コミテーブル]と[口コミポイントテーブル]は、1対多の関係で、
[ユーザーテーブル]と[口コミポイントテーブル]は、多対多の関係になるかと思いますが、
管理者用の口コミ一覧画面の「評価点（平均）」は、[口コミテーブル]をメインとして、[口コミポイントテーブル]からポイント数の平均値を取得すればいいのだろうとなります。
なので、ここにおいては中間テーブルという概念は不要・・かな、と。

Comments

[nobuyuki213]

ご回答ありがとうございます。
また、返答がとても遅くなり申し訳ありません。

また、私の質問の説明不足で不明瞭な中、とてもご丁寧で具体的に実装をするあたってのご説明をいただき、感謝いたします。

ご不要なのかもしれませんが、説明不足であった点を補足させていただきます。

「評価点(平均)」について
これは、ユーザーが大学に対して口コミする時に、大学に対しての点数付けを意味しているものです。
例えば、amazonのある商品に対しての「カスタマレビュー」に、星での5段階評価をするものだとイメージしていただければと思います。

「ポイント付与」について
これは、管理者側だけが、口コミに対してポイント付与するという仕様で考えております。

これほどまでご丁寧なご説明をいただいたのですが、認識にズレが無いように私なりに解釈したことを要点をまとめ、違いがありましたら再度ご指摘いただければありがたいです。

いくつか回答いただいたテーブル設計の案で[口コミ管理テーブル]のようなテーブルを利用するのが良いと感じました。
その上で、リレーションは、

[ユーザーテーブル] 1 対 多 [口コミテーブル] 1 対 1 [口コミ管理テーブル]

となる。

[口コミ管理テーブル]の属性をマイグレーションファイルの形式で置き換えた場合は、

＜カラムのみ抜粋＞
$table->increments('id'); //※初めからある主キー
$table->integer('review_id')->unsigned()->index() //・「どの口コミ」を
$table->datetime('approved_date') //・「いつ（承認された日）」
$table->boolean('is_approved')・「承認したか（承認フラグ）」
$table->string('approved_admin')（・複数管理者であれば、「承認処理したのはどの管理者」）
$table->datetime('points_date')・「いつ（ポイント付与された日）」
$table->integer('points')・「何ポイント付与した（ポイント数）」
$table->string('granted_admin')（・複数管理者であれば、「ポイント付与したのはどの管理者」）

と感じであっておりますでしょうか？

[mix-peach]

他のユーザーが。。は私の思い込みだったようで失礼しました！

テーブルは、そんな感じで良いのではないかと思われます。

管理者がstringになっていますが、一意のidとかないのでしょうか？　というところだけ気になるかな・・
ちなみに口コミデータ1件ありきでの、口コミ管理データ1件なので、口コミ管理テーブルは、idではなく、review_idを主キーにするのでもいいかと思います。（idは使わないautoincrementもしない・・・など、Model側で多少設定が必要になります）
※あくまで方法のひとつなのでid主キーでも、特に問題はないです。

後は、口コミデータの新規作成時に、同時に管理テーブルも1行作る　としておけば、
「あとから管理テーブルのデータだけを新規作成」とかしなくて済むので、データの管理も楽かもです。

[nobuyuki213]

こちらこそ、説明不足で分かりにくくてすみませんでした・・・。

管理者の strign は、[管理者名]を保存対象とするのだと思い込んでおりました・・・。

一意のidはありますので、
$table->integer('approved_admin_id')
$table->integer('granted_admin_id')
にカラムのタイプを変更し[管理者id]で保存に変更します！

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
・口コミ管理テーブルは、idではなく、review_idを主キーにするのでもいいかと思います。
（idは使わないautoincrementもしない・・・など、Model側で多少設定が必要になります）
・口コミデータの新規作成時に、同時に管理テーブルも1行作る　としておけば、
「あとから管理テーブルのデータだけを新規作成」とかしなくて済む
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
↑
このような方法やアドバイスなど、一つ一つ段階的に進めて行きたいと思います！

ご丁寧にご説明をいただいたのですが・・・
もう1つお伺いしたいことがあり、もし差し支えなければご回答をいただければ幸いです。

当初の実現したいことでの流れとしては、
①.ユーザーが大学に対して口コミする
②.管理者が口コミ内容を確認し、承認する
③.口コミに対して任意のポイントを付与する

の①～③でしたが、新たに

④ユーザーは口コミで得たポイントを消費して、モノ(例：商品券など)と交換申請する
⑤管理者は、交換申請を確認し、受理する

と④⑤の機能を実装する場合、
[口コミ管理テーブル]に、
$table->integer('user_id') //「どのユーザー」からの
$table->datetime('applicated_date') // 「いつ（申請された日）」
$table->datetime('accepted_date') // 「いつ（受理された日）」
$table->boolean('is_accepted') // 「受理したか（受理フラグ）」

のカラムを追加する感じで、[口コミ管理テーブル]ひとつにまとめる方法はテーブル設計としては妥当でしょうか？
その他の方法が良いのでしょうか？

Answer 2

仰るようにリレーションの理解が作りたいものに対して追いついていない、というかそこがわかれば残りの疑問も自動的に解決すると思いましたので日本語ドキュメントを案内致します。

https://readouble.com/laravel/5.6/ja/eloquent-relationships.html

Comments

[nobuyuki213]

ご回答ありがとうございます。また、回答に対する返答が遅くなり申し訳ありません。

ご回答いただいた通り、今まで実装したことの無い機能を追加するたびに、リレーションをどのように組めばよいか頭を悩ませており、ご案内いただいた日本語ドキュメントを幾度と読みましたが、理解力が乏しいため、質問という形で具体的なアドバイスをいただきたいと思っておりました。

今回の問題に限らず、問題の解決に導くためにはご案内いただいた日本語ドキュメントを見ることが必要であり、それによって解決することができるのだと改めて気付かせていただきましたので、感謝致します。
また、1日でも早くそうなれるようなスキルを身につけて行きたいと思います。

ご回答をいただき本当にありがとうございました！

[退会済みユーザー]

そうですね、リレーションを理解するにはSQL(RDB)の勉強を別途する必要があるのですよね。
モデルのリレーションはSQLを分かっていないと使えません。
何を見ればわからない場合は『SQL 第2版 ゼロからはじめるデータベース操作』という本をチェックしてみて下さい。

[nobuyuki213]

分かりました！
教えていただいた本を参考に勉強に励みたいと思います。
大変ご親切にしていただきまして、ありがとうございます！

[退会済みユーザー]

頑張って下さい。