画面の操作を、読み書きの一覧へ変える

一覧から絞り込む、番号で1件を開く、関連する履歴を表示するなど、利用者の操作を具体例にします。必要な検索条件と結果の並び順が分かると、データの持ち方を比較しやすくなります。

更新については、同時に成立しなければならない変更を洗い出します。申請と残数、注文と明細のような関係を整理し、一部だけ変わった状態を許容できるかを確認します。

関係を扱うか、決まったキーで探すか

関係を扱うか、決まったキーで探すか関係を持つデータの設計キーを起点にしたデータの設計
確認する検索複数の記録を関連付ける検索や集計事前に決めたキーと範囲による取得
先に整理すること表の関係と同時に更新する単位アクセスする順序とキーの組み合わせ
試すべき変化項目や検索条件が増えたときの影響予定外の検索が必要になったときの影響
選定の姿勢関係と整合性の要件に合わせて候補を比較する既知のアクセス方法と運用条件に合わせて候補を比較する

件数より先に、壊れてはいけない関係を決める

整合性
二重登録や部分的な更新で困る業務を挙げ、成功・失敗をどの範囲で判断するかを定めます。
アクセス権
読める人、更新できる人、集計だけを行う処理を分け、保管方式とアプリ側の制御を合わせて確認します。
変更と保持
項目の追加、削除、保存期間の変更に備え、古いデータの扱いと過去の結果を再確認する方法を整理します。

実データに近い条件で、移行を確かめる

  1. 代表的な入力と検索を選ぶ

    まず架空の代表入力で、実データに近い条件を再現します。通常の記録に加え、欠けた値、重複、長い文章など判断が分かれる例を含めます。実データを使う必要がある場合は、個人情報の有無と扱いを別途確認します。

  2. 元の結果と照合する

    件数だけでなく、代表的な検索結果、関連付け、更新後の状態を比較します。測定条件を残して候補を評価します。

  3. 切り替えと戻し方を決める

    切り替え中の新規入力をどう扱うか、差分をどう移すか、問題があればどの状態へ戻すかを事前に整理します。

方式を選ぶ前の疑問

最初から一つの製品に決める必要がありますか。

まず必要な検索と更新を定義し、その条件で候補を比較します。運用できる体制や移行方法も判断材料に含め、製品名だけで方式を決めないようにします。

データ量が増えたら、必ず別の方式へ移すべきですか。

量だけでは判断できません。実際の検索、更新の偏り、待ち時間、運用上の制約を測り、現方式の見直しと移行の影響を比較します。