弁当宅配サービスを例にとる

​

考える事項

​

• 賞味期限
  • ロットナンバー（製造番号）で管理
  • 基本的にリードタイムおよび賞味期限が短いものから先に出荷する
  • 何らかの理由で賞味期限が前後したものが納品される可能性を考慮する
  • 在庫のロス（廃棄）や納品物の不良があるので、賞味期限以外の在庫が減る理由が存在する ​

​

DBの目的

​

• ロットナンバーで追跡したい
• 製造者責任 ​

---

​

案

• 廃棄マスタは必要か？
  • きれいにやるならあってもよいが、工数を考えて注文テーブルの届け先カラムに「廃棄」、備考に廃棄理由を書いて対応するのも一手 ​

注文テーブル

​

id	注文日	届け日	商品id	数量	届け先	ロットNo.	区分	備考
1	200314	200316	1	4	hoge	200301	注文	-
2	200315	200316	1	2	2	-	廃棄	不良
1	200316	200317	1	10	fuga	200301,200305	注文	-

在庫数量の関係で、使用する在庫数によってはロットNoが複数またく可能性あり

​

入庫テーブル

​

id	注文id	ロットNo.	数
1	1	200301	10
2	1	200301	20
3	1	200305	10
4	1	200301	5​

ロットNo（賞味期限）が前後して入荷する可能性がある
および、賞味期限が短い方から出荷する必要がある

​

商品マスタ

id	品名	カロリー	材料
1	惣菜	200	きゅうり、にんじん
2	コロッケ	430	じゃがいも​

処理速度を考えなかったら

​

1. まずロットナンバー順に納品される
2. 注文データを見て出荷する
3. 在庫が増減する ​ ​

---

​

• 商品マスタ

id	品名
1	ハンバーグ
2	カレー
3	ラーメン

​

• 入庫データ（工場から倉庫）

日付	商品id	ロット	数
0314	1	A0314	100
0314	2	B0314	100
0314	3	C0314	100

​

• 出庫データ(注文データ)

日付	商品id	数	届け先	届け日
0314	1	10	-	0316
0314	2	10	-	0316

---

DBについての考え方

検索、並べ替えのときに使う情報を保存する

SQLに色々とやらせる宗派と、SQLは極力シンプルにしてプログラムに色々とやらせる宗派があるが、

後者の方が良いのではないかと考えている

---

課題

グーグルカレンダーをベースにどんなテーブル構造なのか想像してみる

作成したモデル

Dateマスタ

• id
• Year
• Month
• Date
• 曜日
• timezone
• time

スケジュールマスタ

• id
• start_date
• end_date
• f_終日
• f_loop
• loop_genre
• location
• f_video
• f_alert1~5
• alert_timing1~5
• user
• marker
• schedule_genre
• pub_setting
• memo
• created_at
• updated_at
• deleted_at
• f_guest
• guest_id
• guest_permission
• permission_setting

カレンダーマスタ

• id
• name
• description
• time_zone
• created_at
• updated_at
• deleted_at

ユーザマスタ

• id
• user_name
• email
• created_at
• deleted_at

ユーザ設定マスタ

• id
• display_space
• color
• theme ...

スケジュールジャンルマスタ

• id
• genre_name
• created_at
• updated_at
• deleted_at

マーカーマスタ

• id
• marker_name
• color
• creadted_at
• updated_at
• deleted_at