Accessにおける数値（Number型）の考え方
Accessでシステムを作るとき、
数値（Number型）は「とりあえず使う型」になりがちです。
しかし実務では、
Number型の選択ミスが、後から修正できない問題として表面化する
ケースを何度も目にします。
この記事では、
- Number型をどう捉えるべきか
- Integer / Long / Double をどう判断するか
- VBAやクエリと絡んだときに何が起きるか
を、設計視点で整理します。
Accessの数値型を「型一覧」で理解しようとする危険性
Integer / Long / Double の違いを覚えても解決しない
Accessの解説記事では、
Number型の説明として
- Integer：整数
- Long：大きな整数
- Double：小数
といった一覧がよく出てきます。
しかし実務では、
違いを覚えているかどうかより、
なぜその型を選んだのか説明できるかの方が重要です。
型を暗記しても、
設計判断を誤れば問題は必ず起きます。
数値型はデータ設計そのもの
Number型は、
- 見た目
- 入力フォーム
の話ではありません。
データベース設計そのものです。
一度データが溜まり始めると、
- 型変更ができない
- 影響範囲が大きすぎる
という理由で、
誤った選択を引きずることになります。
AccessにおけるNumber型の位置づけ
Number型は「数字」ではなく「計算対象」
AccessにおけるNumber型は、
単に「数字を入れる箱」ではありません。
- 比較
- 計算
- 集計
を前提とした型です。
そのため、
- 文字列として扱うべきデータ
- 表示用の番号
をNumber型にすると、
後で整合性が崩れます。
数値に見えるがNumber型にすべきでないデータ
代表的なのが以下です。
- 郵便番号
- 電話番号
- 会員コード
- 管理番号（桁や形式に意味があるもの）
これらは、
- 計算しない
- 桁数や表記が重要
という性質を持つため、
文字列型として扱うべきデータです。
Number型の選択が業務に与える影響
集計・クエリ・インデックスへの影響
Number型の選択は、
- クエリの実行速度
- 集計の正確性
- インデックスの効き方
に直接影響します。
特にデータ件数が増えると、
型選択の差がそのままパフォーマンス差になります。
数値型ミスが後から問題になる理由
数値型の問題は、
- 初期段階では表面化しない
- 運用が進んでから顕在化する
という特徴があります。
よくあるのが、
- 桁が足りなくなった
- 計算結果が微妙にズレる
- 型不一致エラーが頻発する
といったケースです。
Integer / Long / Double をどう考えるか
Integer を使う場面がほぼ無い理由
Integer型は、
- 範囲が狭い
- 実務で扱う数値に対して余裕がない
という理由から、
業務Accessではほとんど使う理由がありません。
「小さい数だから」という理由で選ぶと、
後から確実に足りなくなります。
Long が事実上の標準になる理由
Long型は、
- ID
- 件数
- カウント
- 行番号
など、
整数として扱う多くのケースで無難な選択です。
特別な理由がなければ、
IntegerよりLongを選ぶ方が安全です。
Double を選ぶときに注意すべきこと
Double型は、
- 小数を扱える
- 計算が高速
という利点がありますが、
誤差を含む型でもあります。
そのため、
- 金額
- 請求額
- 合計金額
のような用途には、
原則として向いていません。
Currency型との違いと判断基準
金額はなぜNumber型では危険なのか
金額計算にNumber（Double）型を使うと、
- 0.1 + 0.2 が 0.3 にならない
- 集計結果が1円ずれる
といった問題が発生します。
これは計算誤差によるもので、
設計ミスです。
Currency型を選ぶべき典型パターン
以下のようなデータは、
Currency型を選ぶべきです。
- 単価
- 金額
- 請求額
- 支払額
「小数があるからDouble」ではなく、
意味で型を選ぶ必要があります。
VBA・クエリとNumber型の関係
型が原因で起きるVBAエラー
Number型の設計が曖昧だと、
- データ型不一致
- 暗黙の型変換
- 予期しないエラー
がVBAで頻発します。
特にNullを含む場合、
型設計の甘さが一気に表面化します。
クエリでの計算・比較が壊れるケース
クエリでは、
- 異なる型同士の比較
- 文字列と数値の混在
があると、
意図しない結果になります。
これはSQLの問題ではなく、
テーブル設計の問題です。
Number型設計でよくある失敗パターン
とりあえずNumberにしてしまう
設計初期に、
- 迷ったらNumber
- 後で考える
という判断をすると、
後から必ず困ります。
型は、
設計意図を残すための情報でもあります。
Excel感覚で型を選ぶ
Excelでは、
- 数値
- 文字列
の区別が曖昧でも動きます。
しかしAccessは、
業務データベースです。
Excel感覚で型を選ぶと、
長期運用に耐えません。
まとめ｜数値型は「後から直せない判断」
- Number型は軽く見られがち
- 実際は設計の根幹
- 「今動く」より「将来耐える」判断が重要
数値型の選択は、
Access設計者の考え方が最も表れる部分です。
後から修正できない領域だからこそ、
最初に立ち止まって考える価値があります。
システムキューブの「Accessの移行変換、mdb・adpのバージョンアップ」について
