おすすめのDBの設計

Question

昨年自身で作成したECサイトのようなシステムの，DB設計に関する質問です．

前提

Web系の開発（HTML，JS，PHP，MySQL）は半年ほど，Laravelは触り始めて3か月ほど経ちます．
知識も経験も足りませんので，お力をお貸しいただければと思います．

このシステムはHTML，jQuery（JS），MySQL（操作はPDO），PHPとその拡張機能（メール送受信，PDF作成）で作られています．

このシステムをメンテナンスしやすいようにLaravelに移行しようと設計から見直していたのですが，元の機能を維持した移行が難しそうだったので設計が間違っているか，若しくはコーディング技術が足りないか，ご教示いただきたいです．
移行後もDBは変わらずMySQLの予定です．

今までの設計

このシステムにユーザ登録を行うと，ユーザに個別のユニークidが割り当てられ， user_list テーブルに保存されます．
また，同時にユーザ個別の注文テーブルも作成されます．

user_list

user_id	user_name	user_address	password(hashed)
1	hoge太郎	[e-mail]	${hogeHashed}
2	fuga次郎	[e-mail]	${fugaHashed}
⁝	⁝	⁝	⁝

---

ユーザの注文内容等は，ユーザのidを名前に含んだテーブル order_{$user_id} に記録されます．
一度の注文ごとに注文のidが割り当てられ管理されます．

order_2 (fuga次郎の注文内容)

order_id	order_name	order_date	status	…
1	おだんご	20XX_01_01	delivered	⁝
1	おまんじゅう	20XX_01_01	delivered	⁝
2	きんつば	20XX_02_11	cancelled	⁝
3	ようかん	-	in_cart	⁝
⁝	⁝	⁝	⁝	⁝

今回質問したいこと

ユーザごとの処理を軽くする，ユーザごとに注文を管理しやすいなどの観点からメリットがあると考え，このような設計を行いました．
しかしながら，この挙動がLaravelらしいのか（後々にチームでのメンテナンスがシームレスにしやすいか），前述したメリットは実は大きくないのか，Laravel以前にそもそもこのような設計はしてはいけないのか（脆弱性を孕みやすいか） などが質問内容です．

設計案

今のところ思いつく設計としましては，

1. このままLaravelに移行する
2. 注文テーブルを一つにまとめ，その中でユーザidを持ちユーザを区別する

※2 order_table

order_id	user_id	order_name	order_date	status	…
1	1	おだんご	20XX_01_01	delivered	⁝
1	1	おまんじゅう	20XX_01_01	delivered	⁝
2	1	きんつば	20XX_02_11	cancelled	⁝
3	1	ようかん	-	in_cart	⁝
4	2	おだんご	20XX_03_21	delivered	⁝
4	2	おまんじゅう	20XX_03_21	delivered	⁝
5	2	きんつば	20XX_04_30	cancelled	⁝
6	2	ようかん	-	in_cart	⁝
⁝	⁝	⁝	⁝	⁝	⁝

のどちらかですが，メリット/デメリット/その他 ご教示いただけますでしょうか．

Answer 1

テーブル設計についての質問でしょうか？
ユーザーマスターはあるのに商品マスターがないのは片手落ちです
ユーザーマスターと商品マスターをリレーションするオーダーテーブルがあればよいでしょう
オーダー手ブルの仕様はuser_ud,product_id,日付,数量,金額,status
order_name的なものは商品マスターから引っ張ってくるものです

Comments

[退会済みユーザー]

その時の商品マスターは、価格変更など商品情報が変更されても、古い注文の情報が壊れないような設計であってほしいですね。商品情報の有効期間を設けるとか、有効フラグのようなものを設けるとかすれば良さそうですが。

[laravel_prog]

ありがとうございます．
オーダテーブル内でのデータの扱いは，「商品マスタを参照してINSERTするが，飽くまでその時のデータとして持ってくるだけであって，ポインタのように商品マスタの変動によってオーダテーブル内の既存データが勝手に書き換わったりしない」ようにすべきというような意味合いでしょうか．

Answer 2

order_table は1つにまとめるのが普通です。ユーザごとに分けるのは、よくないやり方です。

ユーザごとの処理を軽くする，ユーザごとに注文を管理しやすいなどの観点からメリットがあると考え，このような設計を行いました．

ユーザごとの処理は軽くなるかもしれませんが、商品単位での処理を行うために数千・数万のテーブルを扱う必要があります (例えば集計処理や、発売日到達による出荷のため一括ステータス変更、発売中止による一括キャンセルなど)。カラム追加が発生したときも大変です。

ちなみに少数の法人単位でデータベースやテーブルをわけることはたまにあります (マルチテナント)。
例えば大規模ECサイトサービスを大手スーパーA・大手百貨店B・大手コンビニC に利用してもらうとして、
・法人ごとに要望が異なりテーブル構成も異なる
・セキュリティ上明確にデータベースを分けたい
・ある法人が高負荷になっても他の法人には一切影響がないようにしたい
・似て非なるテーブルがあって開発/運用が複雑でもペイするような利益が見込める
という場合に採用します。ユーザごとに分けるのはメリットがないと思います。

また nukasa さんが提示されているように、注文と注文明細は別テーブルが普通です。
まとめてしまうと、注文単位での処理 (決済・キャンセル・発送など) が管理しづらくなります。

Comments

[68user]

この本をおすすめしておきます。別にこれが正解とは言いませんが、「一般的にはこうする」というのを把握しておいて損はありません。
https://www.amazon.co.jp/dp/4798157384

[laravel_prog]

ありがとうございます．

なるほど．
確かに商品単位での処理や仕様変更等についての配慮が足りていませんでした．
例外（マルチテナント）についても詳細に記述してくださり，考えが及んでいない視点だったので大変為になりました．

（そもそもMVCの設計すらまともにできていませんでしたが，）注文単位での処理については，本来であればPHPのコントローラのような役割を担う場所で行ってしまっていたために管理のし辛さが明確化されておりませんでした．
この処理の管理は本来DBの設計段階で負うべき責務なのですね．

本についてもありがとうございます．
まさにその「一般的にはこうする」の情報が欲しかったので渡りに船でした．

学びが多く，私にとって大変貴重なご回答でした．
ありがとうございました．

Answer 3

注文テーブルを一つにまとめ，その中でユーザidを持ちユーザを区別する

こちらを選択するのは当然として、関係モデルの正規化について勉強しましょう。
まともに正規化すれば、こんな感じになります。

Comments

[laravel_prog]

ありがとうございます．

なるほど．
正規化というのですね．このような図も初めて見ました．
注文自体とその内容も別テーブルで管理するのですね．
確かにその方が管理しやすそうです．

図中の記号等わからないことが多いのでいろいろ調べてみようと思います．
その足がかりとしての良き地図をいただいたような感覚です．
大変貴重なご回答です．
ありがとうございました．

Answer 4

まず、データーベースの正規化をきちんと学んでください。

データベースの正規化とは？
動画データベース設計入門#1 リレーションとER図【11分でマスター！DB設計】

Comments

[laravel_prog]

詳しい記事をありがとうございます．