遷移するステータスを持つDB設計例を教えてください。

前提・実現したいこと

状態が承認待ち→納品待ち→完了等と遷移する場合のDB設計が経験と調べても同じケースが見当たらないので質問させていただきます。

以下のテーブルどちらの設計の方が良いか、また、なにか良い設計例や資料があれば掲示していただけると助かります

現状

動画等の売買できるアプリケーションを開発しています。
実装を進めながら、現在DB設計をを行っています。
(UML等準備していなくてすいません。)

投稿したコンテンツに対して、(オファー) →承認待ち状態 → (承認orキャンセル) →納品待ち状態 → (納品) → 完了のようなフローを購入納品までに想定しています。
※()をアクション、()無し部分を状態とする。

設計例(1 と 2 を記載しました)

購入フローテーブル1

投稿	購入者	状態
movie	user	承認待ち状態

上記の状態カラムを納品待ち→完了と変更していくのはどうでしょうか？　承認日等を後々参照する際に不便？？

購入フローテーブル2-ターゲット

投稿	購入者	要望
movie	user	その他

購入フローテーブル2-オファー承認

key投稿	日付
movie	10/10

購入フローテーブル2-オファー拒否

key投稿	理由	日付
movie	忙しい	10/10

購入フローテーブル2-承認後キャンセル

key投稿	理由	日付
movie	また今度	10/15

購入フローテーブル2-納品完了

key投稿	商品	日付
movie	image_file	10/20

テーブルを状態毎に管理するパターンです
納品場所はステータスの管理とは別で準備したほうがよさそう。ですが構成的にはどうなのでしょうか？

補足情報（FW/ツールのバージョンなど）

DBはpostgresql or Mysql予定です
Djangoでバックエンドの開発を現在進めています。

行動規範の内容に同意します

回答4件

こんな感じはいかがでしょうか？

要望は一方的に伝えるのみなのか、チャットのようにやり取りできるようにするのかにもよると思いますが、やり取りできるようにするなら、下記のようなテーブルを追加してもよいと思います。

オファーした人全員にやり取りが見えることを前提としたので、contents_id に紐付けていますが、offer_idに紐づけて、1対1のやり取りにしてもよいと思います。

投稿2020/10/07 16:17

編集2020/10/08 06:20

takutakuya

総合スコア979

Yuuuya_mmm

2020/10/07 21:48

いつも勉強になります。購入者からの要望、キャンセル理由等はまた別テーブル用意ってイメージでしょうか？？

takutakuya

2020/10/08 03:46

オファーテーブルに持たせてもよいと思いますし、別テーブルでもよいと思います。

Yuuuya_mmm

2020/10/08 10:30

他の方の一つのレコードで管理する方向で進めたいと思います回答ありがとうございます参考になりました！

行動規範の内容に同意します

ベストアンサー

私の場合ですと両案の中間といった形でしょうか
|投稿|状態|ターゲットId|承認日|オファー確認|オファー拒否Id|承認日|キャンセルId|納品日|納品Id|
|:--|:--:|:--:|:--:|:--:|:--:|:--:|:--:|--:|
|movie|納品完了|userid1|2020/10/09|2020/10/10||2020/10/11||2020/10/11|DeliveryId1|
|movie|承認待ち|userid2|||||||DeliveryId2|
|movie|承認|userid3|2020/10/09||||||DeliveryId3|
|movie|オファー確認|userid4|2020/10/10|2020/10/11|||||DeliveryId4|
|movie|オファー拒否|userid5|2020/10/10|2020/10/11|RejectId1||||DeliveryId5|
|movie|キャンセル|userid6|2020/10/11|2020/10/12||2020/10/13|CancelId1||DeliveryId6|
|movie|納品まち|userid7|2020/10/12|2020/10/13||2020/10/14|||DeliveryId7|