リレーションについてのベストプラクティスを知りたい

Question

お世話になっております。
考えていたらしっちゃかめっちゃかになってきてしまい助言を頂きたく投稿しました。
メルカリのようなサービスを考えていて、一人のユーザーは自分の商品を複数登録することができます。
ユーザー1:商品N
この商品は業者アカウントで見ることができてコメントをすることができます。
同様にユーザーも商品に対してコメントをすることができます。

ユーザー　　業者
↓　　↓
コメント
|
商品

最初Laravelの１対多（ポリモーフィック）を使用しようと考えました。

users
id - integer
title - string
body - text

traders
id - integer
title - string
body - text

comments
id - integer
body - text
commentable_id - integer
commentable_type - string

ただこれだとユーザー側が自分の登録した商品詳細を見た時、業者が商品詳細を見た時に自分のコメントしか抽出できないのでは？
と思い分からなくなってきてしまいました。
ユーザー側が自分の商品詳細を見ても、業者が商品詳細を見ても、商品に紐付くコメントは新着順に全件見れれば良いだけという仕様で、単純に、
商品1:コメントN
の紐付けのみでコメントテーブルには「ユーザー」「業者」のどちらがコメントしているのか判別できるカラムだけ用意しておけばいいのかな？
と考えたんですが間違っているでしょうか？
こういう形の場合のよくあるリレーションの設計方法があればご教示いただけないでしょうか。

何卒よろしくお願いいたします。

Answer 1

こちらに自分が回答した同様の問題があります。
参考になるかと思います。
https://teratail.com/questions/221911#reply-325162

Comments

[paranoaman1217]

ご回答いただきありがとうございます！
拝見させていただき、一点質問させていただきたいのですが、エンドユーザーと、業者で登録内容が全く異なる場合Kosuke_Shibuya様ならどのような設計にしますでしょうか？
参考までご教示いただけないでしょうか？

[退会済みユーザー]

「エンドユーザーと、業者で登録内容が全く異なる」
コレについての詳細な仕様を具体例を添えてご説明願います。
それがないので、具体的な回答が困難です。

[paranoaman1217]

情報が足らずすみません。。

Schema::create('users', function (Blueprint $table) {
$table->bigIncrements('id')->comment('ID');
$table->string('user_name')->nullable()->comment('ユーザー名');
$table->string('email')->unique()->comment('メールアドレス');
$table->string('password')->nullable()->comment('パスワード');
$table->timestamp('email_verified_at')->nullable()->comment('メール認証用');
$table->rememberToken();
$table->timestamps();
});

Schema::create('traders', function (Blueprint $table) {
$table->bigIncrements('id')->comment('ID');
$table->string('company_name')->nullable()->comment('会社名');
$table->string('public_email')->unique()->comment('公開用メールアドレス');
$table->string('company_email')->unique()->comment('管理者用メールアドレス');
$table->string('public_tel')->unique()->comment('公開用電話番号');
$table->string('company_tel')->unique()->comment('管理者用電話番号');
$table->string('password')->nullable()->comment('パスワード');
// 定休日、営業時間、創業年月日、サイトURL、紹介文、店舗住所（複数）、スタッフ（複数）etc...
$table->rememberToken();
$table->timestamps();
});

業者のテーブルに関してはまだ作っていませんが、概ね入りそうなフィールドをコメントアウトで記しました。当初の想定では登録内容もだいぶ違うのでマルチ認証を検討しておりました。

[退会済みユーザー]

traders の時にログインに利用するのはどちらのメールアドレスですか？

[paranoaman1217]

$table->string('company_email')->unique()->comment('管理者用メールアドレス');
こちらになります！
エンドユーザーと業者アカウントではログイン場所もそれぞれ用意します。

[退会済みユーザー]

自分だったら、users はあくまで共通。業者独自のデータのみ、TraderMeta とか用意して、User と TraderMeta を　HasOne で定義しますね。

[退会済みユーザー]

その方が、Policy を利用することで、権限を分けたり、middleware を利用してroute を管理しやすくなるからです。

[退会済みユーザー]

提示されたカラムの様子を見ると、trader => companies とする方が自然ですね。

[paranoaman1217]

ご回答いただきありがとうございます！
構成考え直してみました。

$table->bigIncrements('id')->comment('ID');
$table->unsignedBigInteger('role_id')->after('id');
$table->string('email')->unique()->comment('メールアドレス');
$table->string('password')->nullable()->comment('パスワード');
$table->timestamp('email_verified_at')->nullable()->comment('メール認証用');
$table->rememberToken();
$table->timestamps();

usersテーブルでエンドユーザー、業者アカウント共通で使えるフィールドを用意し、それぞれの独自データはTraderMeta、UserMetaを作成する。
私的にもすごくスッキリしました！
大変参考になりました！

Answer 2

ユーザー関連のテーブルをひとつにしてユーザータイプで区分けした方がスッキリすると思います。
同じ定義ならなおさら分ける意味がないかと

Comments

[paranoaman1217]

ご回答いただきありがとうございます！
エンドユーザー側では新規会員登録からメール認証などを行いログインする仕様です。
一方業者側は一般問い合わせから運用サイドで業者を審査し、ログインアイパスを発行するような形で
ログインページも分ける想定です。登録内容はエンドユーザーと業者アカウントでは全く違う内容にまります。
アカウント管理用の中間テーブルを作成し、ユーザー、業者用のテーブルを作るとかだと一限管理もできてコメントも取れそうでシンプルな設計になりそうですね。
検討します、ありがとうございます！

[m.ts10806]

ログインページ分けるのでしたらテーブル同じでも送り元によって区分を固定値で渡しやすくなるのではと思います。

[paranoaman1217]

ご回答いただきありがとうございます！
今の構造を見直すいい機会なのでトライしみます、ありがとうございました！

Answer 3

Laravelはよくわかんないけど、UserとTraderはどう違うのかがちょっと疑問。

まぁリレーションの設計という意味では、商品1：コメントNにしておいて、usesrs(id)-comments(id)の関連とtraders(id)-comments(id)の関連をそれぞれ別テーブルに持っておけば、全部JOINすることも区別することもできると思いますが。

Comments

[paranoaman1217]

ご回答いただきありがとうございます！
エンドユーザー側のアカウントと、業者側のアカウントの2種類ありまして、ユーザーの登録商品を業者アカウント側で査定するようなCtoBのサービスを考えています。その際に商品に対してのやり取りをコメントで残せる機能（メルカリと作りは全く同じだと思います）がありまして、1テーブルで管理しようと考えていました。
シンプルにテーブル分ければ直感的ですし取り回しはしやすそうです！
ありがとうございます！
Laravelのドキュメントを見ていると色々な紐付きができる機能があったので端から見ていたらよく分からなくなってきてしまっていました汗

[gentaro]

UserとTraderの違いが気になった原因でもありますが、質問文の定義だとcommentsテーブルにidとcommentable_idというIDを表すカラムが２つあって、それぞれ何を入れるつもりか読み取れませんでしたが、おそらく１つはusersやtradersテーブルに対するリレーションを表す目的だと思います。

で、UserとTraderが概念的に違うもの（別テーブルに分ける相当の理由があるもの）であれば、それぞれのIDに対してリレーションを貼るためのカラムが必要になるはずで、comment自体のIDと合わせて３つないとおかしいわけです。

UserとTraderの「いずれかのID」が入るつもりでカラムの設計をしているとしたら、それは大間違いだと思いました。（ひとつの概念に対してひとつのIDであるべきで、異なるIDが同一のカラムに入る設計はおかしい）

[paranoaman1217]

ご回答いただきありがとうございます！
私も当初その形を考えていて、

comments
id - integer
user_id - integer
trader_id - integer
body - text

エンドユーザー、業者双方で登録があった時に
id - 1
user_id - 1
trader_id - null
body - test1

id - 2
user_id - null
trader_id - 1
body - test2

このような形を考えていたんですが、Laravelでポリモーフィックというリレーションルールがあり、
comments
id - integer
body - text
commentable_id - user_id,trader_id
commentable_type - 区分けをするためのモデル名（App\Models\UserやApp\Models\Traderが入る）

おそらくコメントにまつわる全て（商品のコメント以外でも使う）を1テーブルで管理できるような方法があり導入できないかなと考えていました。
ご回答いただき今の設計の大元を崩さずに行くのであれば、当初の
comments
id - integer
user_id - integer
trader_id - integer
body - text

上記の形が一番今の私のベストかもしれません。ただuser_id,trader_idどちらかがnull値になってしまうのでそこが気になります。

[gentaro]

> ただuser_id,trader_idどちらかがnull値になってしまうのでそこが気になります。

回答はそこを加味して考えた上でのものです。

[paranoaman1217]

ご回答いただきありがとうございます！
この方法が今の構造を見直さないで実装できるので今後採用する可能性もありますが、
元々のユーザーデータの構造を見直すいい機会なのでまずはそちらにトライしてみようと思いました。
その上でどのみち振り分けが必要になりそうなので上記方法で実装しようと思います！
ありがとうございました！