Q&A
回答ありがとうございます。
理解できてなくて申し訳ないのですが、これは承認待ちから承認された場合は、状態を変更して、更新した日時を追加するイメージでしょうか？
前提・実現したいこと
状態が承認待ち→納品待ち→完了等と遷移する場合の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件
0
こんな感じはいかがでしょうか？
要望は一方的に伝えるのみなのか、チャットのようにやり取りできるようにするのかにもよると思いますが、やり取りできるようにするなら、下記のようなテーブルを追加してもよいと思います。
オファーした人全員にやり取りが見えることを前提としたので、contents_id に紐付けていますが、offer_idに紐づけて、1対1のやり取りにしてもよいと思います。
投稿2020/10/07 16:17
編集2020/10/08 06:20
総合スコア979
0
ベストアンサー
私の場合ですと両案の中間といった形でしょうか
|投稿|状態|ターゲット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|
基本の状態は1テーブルで付随する情報が発生する場合は、サブのテーブルへとします。
一覧で確認する際は細かい理由などいらないはず。
それは詳細画面で個別確認できればよいですし、後からSQLで結合する事も可能。
追記
承認待ち・承認・納品まち時のレコードおよび承認日・納品日項目を追加しました。
とこんな感じでしょうか？
注意点
巻き戻しも考慮しておいた方が良いですよ。
例として一度「オファー拒否」として、あとから「オファーOK」とできて、また履歴が残るように。
投稿2020/10/07 14:46
編集2020/10/08 04:06
総合スコア2506
そうです。(追加ではなく更新ですが)
この設計で進めていきたいと思います。ありがとうございました！
0
趣味で学習中なので、薄っぺらい知識ですが。。。
イベント・ソーシングという考え方があります。
差し戻しが複数回発生する可能性があり、かつその事由が重要なシステムとは親和性が良い設計だと思います。
投稿2020/10/08 03:37
退会済みユーザー
総合スコア0
0
以下のテーブルどちらの設計の方が良いか
１は一つのテーブルで管理、２は複数のテーブルで管理という事でしょうか？
複数で構成されても良いでしょうけど、その場合でも基本的な管理のテーブルを軸に、詳細用に別なテーブルを用意する方が良いでしょうね。
なにか良い設計例や資料があれば掲示していただけると助かります
「テーブル設計 状態遷移」や「テーブル設計 ワークフロー」あたりで検索すれば良さそうです。
「マイルストーン」というキーワードについても調べてみる価値はあると思います。
投稿2020/10/07 14:35
編集2020/10/07 14:38
総合スコア25327
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2020/10/07 21:48
2020/10/08 03:46
2020/10/08 10:30