一時保存の設計
このページは、データの一時保存の設計について考えるページです。
目次
注意
- このページを作ったひとが現在進行形で考えていることのため随時内容が変わることがあります。
「一時保存」？
- 下記のケースで使用する
- ① 画面上でのデータ入力時、入力の途中で保存する
- 入力する必要のある項目が多い場合に要望が出やすい
- ② データはすべて入力したが、まだ正式データにせずにしておく (公開したくないなど)
- ブログなど
- ① 画面上でのデータ入力時、入力の途中で保存する
- 「下書き保存」とも呼ぶ
データの管理方式 (DB)
一時保存テーブル方式
一時保存専用のテーブルを作り、自動で確定するデータ以外の手入力データをすべてシリアライズ化 (JSON など) して保存する方式です。
データの例
| 内部ID | 日付 | データ |
|---|---|---|
| 1 | 2020-01-01 | { "title": "記事1", "content", "", ... } |
| 2 | 2020-01-02 | { "title": "記事2", "content", "", ... } |
| 3 | 2020-01-03 | { "title": "記事3", "content", "", ... } |
| 4 | 2020-01-13 | { "title": "記事4", "content", "", ... } |
| 5 | ： | ： |
| 項目 | 説明 |
|---|---|
| 利点 | ・データの必須項目を考慮する必要がない |
| 留意点 | ・テーブルを増やす必要があるので一時保存が必要なテーブルが多い場合煩雑になる可能性がある |
同一テーブル方式
正式テーブルで一時保存データも管理する方式です。
データの例
| 内部ID | 日付 | タイトル | 本文 | 状態 |
|---|---|---|---|---|
| 1 | 2020-01-01 | 記事1 | 本文 | 1 (公開) |
| 2 | 2020-01-02 | 記事2 | 本文 | 2 (下書き) |
| 3 | 2020-01-03 | 記事3 | 本文 | 2 (下書き) |
| 4 | 2020-01-13 | 記事4 | 本文 | 2 (下書き) |
| 5 | ： | ： | ： | ： |
| 項目 | 説明 |
|---|---|
| 利点 | ・テーブルを増やす必要がない ・②のケースでは扱いやすい |
| 留意点 | ・必須項目が多いテーブルの場合は採用できない (①のケースだと未入力で保存する可能性が高いため NOT NULL 制約の多いあるテーブルだと保存できなくなる。テーブルの NOT NULL 制約を外すと正式データの保証が DB レベルではとれなくなる) |
UI 方式
「一時保存」ボタン
通常の保存ボタンの横などに「一時保存」のボタンを用意する方式です。
| 項目 | 説明 |
|---|---|
| 利点 | ・一時保存したい時の操作が1ステップで済む (「一時保存」ボタン押下) |
| 留意点 | ・保存ボタンが2つにわかれる (ボタンの色や配置を工夫する必要がある) |
「一時保存」チェックボックス
通常の保存ボタンの手前などに「一時保存」のチェックボックスを用意する方式です。
| 項目 | 説明 |
|---|---|
| 利点 | ・保存ボタンを1つにできる |
| 留意点 | ・一時保存したい時の操作が2ステップになる (チェック→保存ボタン押下) |
状態プルダウン
一時保存を含めた状態を選択できるプルダウンを用意する方式です。
| 項目 | 説明 |
|---|---|
| 利点 | ・「正式」(公開など)、「一時保存」(一時保存) 以外にも状態がある場合にボタンに比べて画面の幅を取らなくてすむ |
| 留意点 | ・一時保存したい時の操作が3ステップになる (プルダウンクリック→「一時保存」選択→保存ボタン押下) |