開発者がフィールド設計を行う際には、主にフィールドのタイプと長さを考慮する必要があります。本記事では、いくつかのシナリオにおける文字列型の推奨値を示し、開発者がフィールド設計を規範化するのに役立てることを目的としています。
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が浮動小数点数を保存する場合、書き方は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乗。