画面の操作を、読み書きの一覧へ変える
一覧から絞り込む、番号で1件を開く、関連する履歴を表示するなど、利用者の操作を具体例にします。必要な検索条件と結果の並び順が分かると、データの持ち方を比較しやすくなります。
更新については、同時に成立しなければならない変更を洗い出します。申請と残数、注文と明細のような関係を整理し、一部だけ変わった状態を許容できるかを確認します。
関係を扱うか、決まったキーで探すか
| 関係を扱うか、決まったキーで探すか | 関係を持つデータの設計 | キーを起点にしたデータの設計 |
|---|---|---|
| 確認する検索 | 複数の記録を関連付ける検索や集計 | 事前に決めたキーと範囲による取得 |
| 先に整理すること | 表の関係と同時に更新する単位 | アクセスする順序とキーの組み合わせ |
| 試すべき変化 | 項目や検索条件が増えたときの影響 | 予定外の検索が必要になったときの影響 |
| 選定の姿勢 | 関係と整合性の要件に合わせて候補を比較する | 既知のアクセス方法と運用条件に合わせて候補を比較する |
件数より先に、壊れてはいけない関係を決める
- 整合性
- 二重登録や部分的な更新で困る業務を挙げ、成功・失敗をどの範囲で判断するかを定めます。
- アクセス権
- 読める人、更新できる人、集計だけを行う処理を分け、保管方式とアプリ側の制御を合わせて確認します。
- 変更と保持
- 項目の追加、削除、保存期間の変更に備え、古いデータの扱いと過去の結果を再確認する方法を整理します。
実データに近い条件で、移行を確かめる
- 代表的な入力と検索を選ぶ
まず架空の代表入力で、実データに近い条件を再現します。通常の記録に加え、欠けた値、重複、長い文章など判断が分かれる例を含めます。実データを使う必要がある場合は、個人情報の有無と扱いを別途確認します。
- 元の結果と照合する
件数だけでなく、代表的な検索結果、関連付け、更新後の状態を比較します。測定条件を残して候補を評価します。
- 切り替えと戻し方を決める
切り替え中の新規入力をどう扱うか、差分をどう移すか、問題があればどの状態へ戻すかを事前に整理します。
方式を選ぶ前の疑問
最初から一つの製品に決める必要がありますか。
まず必要な検索と更新を定義し、その条件で候補を比較します。運用できる体制や移行方法も判断材料に含め、製品名だけで方式を決めないようにします。
データ量が増えたら、必ず別の方式へ移すべきですか。
量だけでは判断できません。実際の検索、更新の偏り、待ち時間、運用上の制約を測り、現方式の見直しと移行の影響を比較します。
