フィールド設計

開発者がフィールドを設計する際には、主にフィールドの型と長さを考慮する必要があります。本記事では、いくつかのシナリオにおける文字列型の推奨値を示し、開発者がフィールド設計を標準化する一助とします。

MySQLモード

• 数値型フィールド

  将来的な範囲オーバーを防ぐため、int、smallint などの整数型に代わり、bigint 型の使用を推奨します。

• 文字型フィールド

  • すべての動的文字列は、VARCHAR(N) 型を使用することを推奨します。

  • 単一文字のみを格納するフィールドには CHAR(1) を使用します。はい/いいえの概念を表すフィールドでは、スペース節約のため CHAR(1) 型を使用することを推奨します（1 は TRUE、0 は FALSE を表します）。値の内容とアプリケーションでの値の解釈は統一してください。例：論理削除を表すフィールド名 is_deleted では、1 が削除、0 が未削除を表します。

  注意

  NUMBER(1) もはい/いいえの概念を表現できますが、より多くのスペースを消費します。

  • 列の型として NVARCHAR、NCLOB などの型の使用は禁止されています。

  注意

  文字データ型の列はすべての英数字を格納できますが、NUMBER データ型の列は数字のみを格納できます。

• 日付時刻フィールド

  • 時刻の精度が必要な業務では、datetime(6) を使用できます。

  • 精度が不要な場合は、datetime に設定します。

  • 将来的に国際化が必要になる可能性がある場合は、timestamp の使用を推奨します。

  • 時刻フィールドのデータ型として文字を使用することは推奨されません。使用すると暗黙的な型変換が発生しやすくなります。

• データフィールドの選択に関する推奨事項

  特に大規模なテーブル（百万件レベル）では、以下の方法を推奨します：

  • 業務内の各テーブルの日付時刻フィールドは必ず統一し、DATE 型の使用を推奨します。精度が高い業務では TIMESTAMP 型を使用できます。

  • IP アドレスを格納するテーブルが大規模な場合、ストレージ容量を節約するために NUMBER 数値型の使用を推奨します。フロントエンドで変換を行います。使用する数値範囲はネットワークセグメントデータと一致させてください。

  • 業務ニーズに応じて、IPv4 と IPv6 を別々のフィールドに格納し、VARCHAR(N) 型を使用することもできます。

Oracleモード

• 数値型フィールド

  • NUMBER 型の使用を推奨します。NUMBER が可変長の10進数精度固定小数点数を格納する場合は NUMBER(p,s) の形式で、浮動小数点数を格納する場合は NUMBER の形式で記述します。

  • 小数型のフィールドには DECIMAL の使用を推奨し、BINARY_FLOAT および BINARY_DOUBLE の使用は推奨しません。BINARY_FLOAT と BINARY_DOUBLE は格納時に精度損失が発生する可能性があり、値の比較時に誤った結果が得られる可能性があります。

  • 暗黙的な型変換時の優先順位

    BINARY_DOUBLE の優先順位が最も高く、次に BINARY_FLOAT、最後に NUMBER です。

  • 数値フィールドの取り得る値の範囲

    型	値の範囲	長さ(バイト)
    NUMBER	1.0 E-130F ~ 1.0 E +126 F（1.0 E +126 Fを除く）	4~40
    BINARY_FLOAT	1.17549E-38F ~ 3.40282E+38F	4
    BINARY_DOUBLE	2.22507485850720E-308 ~ 1.79769313486231E+308	8

• 文字型フィールド

  • VARCHAR2 の使用を推奨します。

  • VARCHAR2 型を比較する場合は、非補完空白モードで比較されます。一方、CHAR 型を比較する場合は、補完空白モードで比較されます。

  • 日付時刻フィールド

    • TIMESTAMP WITH TIME ZONE と TIMESTAMP WITH LOCAL TIME ZONE の 2 種類はタイムゾーンを認識します。タイムゾーンの違いにご注意ください。

    • 時刻フィールドのデータ型として文字を使用することは推奨されません。使用すると暗黙的な型変換が発生しやすくなります。

その他

• 自動インクリメント列：ストレージオーバーフローを防ぐため、int型の使用は禁止され、必ずbigint型を使用する必要があります。

• 重複削除を回避するため、外部キーによる自己参照や、テーブルフィールド制約によるカスケード削除・更新の定義は禁止されています。

• 列挙型（enum('x','y','z'),）の使用は可能な限り避けてください。代わりに文字列型を使用してください。

• フィールドの意味を変更したり、表現する状態に追加情報を加えたりする場合は、フィールドコメントを適時に更新する必要があります。

• パフォーマンス向上のため、フィールドには適度な冗長性を許容しますが、データ同期の観点からも考慮する必要があります。冗長フィールドは以下の条件を満たす必要があります：

  • 頻繁に変更されないフィールドであること

  • 超長いフィールドではないこと

• 暗黙的な型変換が発生する場合、数値型は時間型よりも低い優先順位を持ち、文字型およびその他すべてのデータ型よりも高い優先順位を持ちます。

• 適切な文字列の格納長は、データベーステーブルのスペースとインデックスのストレージを節約するだけでなく、何よりも検索速度を向上させます。

  無符号値は負の数値を誤って格納するのを防ぎ、表現範囲を拡大します。異なる数値範囲には異なるデータ型を推奨します。例：

  対象	年齢範囲	型	表現範囲
  人	150歳以内	unsigned tinyint	符号なし値：0 から 255。
  龟	数百年	unsigned smallint	符号なし値：0 から 65535。
  恐竜化石	約数千万年	unsigned int	符号なし値：0 から約43億。
  太陽	約50億年	unsigned bigint	符号なし値：0 から約10の19乗。