表計算とデータベースは、人数より「守りたいルール」で選ぶ

データが増えたからという理由だけで移行すると、保存先を変えても入力ミスや修正漏れが残ります。この記事では、現在の困りごとを「守りたいルール」へ翻訳し、表計算の改善で済むか、データベースを含む仕組みが必要かを判断するメモを作ります。

公式仕様で確認できること：制約を定義できる

PostgreSQLの公式資料では、必須の値を求めるNOT NULL、重複を防ぐUNIQUE、一意かつ空でない識別子を定める主キー、別の表との対応を保つ外部キーなどの制約が説明されています。定義した制約に違反するデータの登録・更新はエラーになります。

ただし、データベースを導入するだけで適切な制約が生まれるわけではありません。変更履歴、利用者別の権限、入力画面、同時更新時の扱いも別途設計します。表計算側で使える入力チェックや権限制御も製品・運用によるため、実際の要件に照らして比較します。

仕事の具体例：受注一覧の「1行」を先に決める

架空の受注一覧で、同じ注文IDが複数行に出てきたとします。1行が注文1件なら重複かもしれませんが、1行が注文内の商品明細なら、同じ注文IDが並ぶのは自然です。「注文ID＋明細番号」を一意にするなど、まず行の意味を決めます。

• 顧客名の修正が各行に必要：顧客IDと顧客一覧を分ける案を検討する。存在しない顧客IDを登録させないルールも考える。
• 金額を誰が変えたか分からない：変更者・時刻・変更前後を残す必要があるか決める。制約だけで履歴は残らない。
• 同じ注文を同時に修正して内容が戻る：競合を検知する方法と、競合時に誰が判断するかを考える。

コピーして使える選定メモ

対象業務／データの責任者：
1行が表すもの：注文／明細／その他
識別子：単独のID／組み合わせ
困りごと | 守りたいルール | 表計算での対応案 | 別の仕組みでの対応案
重複 |  |  | 
必須項目の空欄 |  |  |
関連する一覧との不整合 |  |  |
同時更新・変更履歴・権限 |  |  |
入力／検索／集計／修正を行う人：
現在のデータでルール違反のある件数：
保守担当／運用負担／戻す方法：
採用案／理由／未確認事項：

結果の確認ポイント：移行先より照合方法を先に用意する

選んだ案で、重複ID・必須項目の空欄・存在しない参照先をどう扱うか説明できるか確認します。修正担当と、例外を認める場合の判断方法も必要です。単純な表の入力ルールを整えるだけで目的を満たすなら、移行を急ぐ必要はありません。

移行する場合は原本を保持し、テスト用のコピーで照合します。件数だけでなく、IDごとの値、金額の合計、日付、空欄とゼロの区別、先頭にゼロのあるコードを確認してください。行を注文と明細に分けた場合は単純な件数一致ではなく、元の注文がどの注文・明細へ対応したかを照合します。戻す手順が決まるまで本番データを置き換えないことを提案します。

今日試すこと

今の表で困ることを3つ書き、各項目に守りたいルールを1つ対応させてください。「大人数だから」ではなく、必要なチェックと運用負担を比較する材料になります。

参考資料

• PostgreSQL｜Constraints：NOT NULL、UNIQUE、主キー、外部キーなどの定義と働き。

記事一覧へ戻る