「下書き」「一時保存」という要件を甘く見積もってはいけない

「一時保存や下書きできるようにしたい」といった要望が出てくることがあると思います。世の中のサービスでよくある機能ですしあったら便利だなと思うのも当然です。 同じ要望を受けた当時の私はその大変さに全く気づいていませんでした。 意外と考えることが多いよ、というのが伝わると幸いです。 当初明確になっていた仕様 入力フォームには必須と任意の項目があるが、必須項目が未入力状態でも一時保存できる 入力フォームにはファイルを添付できる 正式データと一時データは同じ一覧ビューの中で両方とも表示させる 一時データはユーザー単位ではなく共有される（誰かが作った一時データは自分も閲覧編集できる） 一時データは正式データに対してひとつのみ存在できる 最終的には上記以外にももっと細かい仕様になったのですが、この後の検討や設計の流れに沿って随時記載していきます。 データの持ち方の方針 方法としては以下二つの案がありま

[diveto]

一時データと本データを対にしようとするから面倒な事になるんじゃ？ユーザーが触るのは必ず一時、本データは必ず一時からコピー。コピーされた一時は削除。本データ触りたいなら新一時にコピーして触る。

[rryu]

これは下書きじゃなくて1段階のリビジョン機能だよな。なので状態遷移として設計すると色々無理が出る。プレビュー機能が割と高度な機能とされるのはこういうのが原因である。

[izoc]

分かる。混ぜるな危険。変にカチッと作ろうとせず一時テーブルにjson形式で保存とかで良い気がするわ。メンテも楽だし

[ka-ka_xyz]

ユーザーが必要としているのは本当に「下書き」なのか（共有テンプレ保存機能とかで無いのか）みたいな要求の掘り下げと仕様の再検討が必要な場面な気はする。

[toro-chan]

確かに甘く見積もっちゃいけない奴。むしろ「一時」の方が実装難しいまである。データ保存は表示よりはるかに難しい。でもそういうと冷たい目で無能判定される。。

[prograti]

WordPressは確かリビジョンで管理してましたね。jsonとかシリアライズは古いデータが残ったまま途中で改修が入るとデータ移行忘れで不具合の原因になったりするから保守の引き継ぎがちゃんと出来ないとツラいかも

[yojik]

ユーザとのインタラクションは必ず一時テーブル（名前も悪くてドラフトxxxとかにしたい）経由にして、正式保存・編集開始等のタイミングで同期する方が楽。なんならドラフトの概念をユーザにも浸透させた方が親切

[satomi_hanten]

あんまりないなぁ、Web業務だと「元に戻す」を実装してくれって言われて発狂することはある。「なんでもWebで出来るやろ」「Excelで出来ることをやりたいだけなんや」っていう奴ほんと嫌い。

[regularexception]

一時保存なんてユーザ側の問題なんだから、クライアント（ブラウザ）に保存するようにすればいいんじゃないかな。cookieなりlocal storageなり。

[kagehiens]

下書き機能は・・・、似た機能であっても仕様によってまるっきり作るべき内容が違うから「よくある機能すぎる」なんてことは全然ないぞ!?

[tmatsuu]

添付と共有があるととたんに難しくなるな。自分も一時用テーブルを使うと思う。その方が正式用を取得する際のクエリーも簡単になるしね。

[nisisinjuku]

Wiki的なナレッジDBかな？要望と仕様の指定が混在しててヤバみ。テーブルは1つとする。ではないよな。「持ち帰って再見積もり」世界の工数アップが瞬時に見込めたので（おそらく訂正なども困難に）一旦止話をめるしか

[hatest]

以前やったものだと同様の仕様で、単一テーブル・必須もnullableでデータ持って、別途各項目のエラーを格納するテーブルを作った。エラーテーブルにエラーなくなったら正式、まだエラーあれば一時保存データと扱う

[umaemong]

でも、こういうの考えてるときが一番楽しい。JSONでも要件は満たせそうだけど、サクッと集計できないよなーとか。

[peatnnuts]

ここに複数タブで開くユーザーが登場します。 さらに一つのアカウントを使い回すユーザーも現れます。

[sabinezu]

考えすぎなんじゃないの？だから工数が膨らむんだぞ？

[pixmap]

むしろ、下書きを管理するアプリとして設計・実装・運用した方がいいと思う。「本データ」のアプリはpublishingで下書きアプリからエクスポートされたデータをサーブするだけ、みたいな。

[vndn]

『正式データと一時データは同じ一覧ビューの中で両方とも表示させる』『一時データはユーザー単位ではなく共有される』ひっ / 正式データ1つに対し、一時データはたかだか1つなんだろうか

[taruhachi]

一時保存なんてね、バリデーションも何も必要なくただのデータオブジェクトで良いんじゃね？ユースケース次第だけど。複雑なものを複雑なままでなく、どれだけシンプルな形に落とし込むかが重要だと思ってる。

[ene0kcal]

同一テーブルで保存管理した方が良い気がする。バリデーションなんて必須項目の正当性確認なんだから仕様としては静的性質。やっつけ作業の類だと思うけど違うのかな？

[yarumato]

“入力フォームの必須項目が未入力状態でも、一時保存できる仕様。この検討や設計では、意外と考えることが多いよ、”

[pmint]

正式／一時が共存するのがそもそもの間違い。一時であっても、共有するなら第二の正式データになる。データベースのnullはアンチパターンなので使えない。添付ファイルは正式／一時でそれぞれにあったほうがいい。

[n314]

一時保存フラグを使いつつ、条件付きでnot nullを付けるのが楽そう。not null制約じゃなくてcheck制約になるかな。項目がほぼ同じテーブルって、時間が経つと項目が異なってきたりしちゃうこともある…。

[napsucks]

なぜ正式データをいじれる必要があるのかな

[nanana_nine]

ステータスで管理しないのか

[tasukuchan]

“一時”

[ginga0118]

状態管理でいいんじゃない

[hryord]

仕様、要件をはっきりさせた方が良いと思う。下書きや一時保存をしたい理由やどういう時に本データにするのか、その際の下書きはどうなるのかなど。一時保存できると書いただけで実は要件を詰めれてない気がする

[srng]

一時保存を共有するってなんか仕様がきもいような気が

[Insite]

下書き機能は不要になれば復元不可能にしなければならないというクリティカルな要件がある。浮気に利用されるので。

[Falky]

『プロダクト特有の都合で、その添付ファイルは正式データと一時データとで共有して保持される仕様』えぇ…

[strawberryhunter]

私はJSONよりテーブル。WordPressは同一テーブルでリビジョンを管理していて、何か嫌な感じがするが、一時データ用にテーブルを分けることがいいのかどうか、わからないので結論は保留。

[Lumin]

一時保存データとかあとでブラウザで読むためだけのデータなんやからjsonでてきとーでええねん。状態ちゃうねんそれは。なんでこれがわからんやつが多いかな

[hirano1975]

学び

[PrivateIntMain]

正式になった一時データも消さずに残しといて、しれっと正式ですよで表示させたい。もちろん正式テーブルは別にいてそっちが必要な人はそっちを見ればいい。データ量が倍になるのでいずれ破綻するけど。

[poliphilus]

複数のテーブルのリレーションを取ってるデータで「編集を管理人の承認制にしてほしい。編集前と後を比較できるように」って言われて断った事がある。恐ろしく大変。はじめからそう設計してないとなおさら