答え。

SQLには、文字列型（例えば、VARCHAR、CHAR、TEXT）、数値型（INT、DECIMAL、FLOAT）、日付と時刻型（DATE、TIMESTAMP）など、いくつかの主要なデータ型があります。特定のデータに対して最小限の適切な型を選択することは非常に重要であり、これによりスペースを節約し、インデックスを最適化できます。一般的な間違いは、冗長な長さの型（例えば、VARCHAR(255)の代わりにVARCHAR(50)）を選択することで、これによりリソースの無駄遣いが発生する可能性があります。

もう一つの重要な違いは、数値型です：FLOATは近似値を格納し、DECIMALは正確な値を格納します。これは金融取引に役立ちます。異なるエンコーディングの文字列を比較することは、COLLATEを考慮しないと予期しない結果をもたらす可能性があります。

例：

-- 型不一致での作業例
declare @price varchar(10) = '100.99';
select @price + 1;
-- エラー: 文字列と数値を足すことはできません
-- 明示的な型変換がなければ動作しません

トリッキーな質問。

質問: VARCHAR型のフィールドを数値と比較した場合、例えば：WHERE code = 123はどうなりますか？インデックスは迅速に機能しますか？

答え: SQLは数値を文字列に変換して文字列として比較しようとします。しかし、そのフィールドに数値インデックスが構築されている場合、文字列比較では使われず、クエリは遅くなります。厳密なデータ型と明示的な型変換を常に使用することをお勧めします。

例：

SELECT * FROM products WHERE code = '123'; -- インデックスが使用される可能性があります
SELECT * FROM products WHERE code = 123;   -- インデックスは使用されず、フルスキャンの可能性があります

---

物語

オンラインストアでは、「価格」フィールドが異なる通貨フォーマットをサポートするためにVARCHARとして保存されていました。数年後、商品を価格でソートする必要がありましたが、ソートが正しく機能せず、インデックスが使用できませんでした。複雑な移行と型変換が必要になり、数週間かかりました。

物語

ある銀行では、開発者が合計を保存するためにFLOAT型を使用しました。レポートの際に丸めのために不一致が発生し、1年後にはボーナスの分配に重大な誤りをもたらしました。

物語

スタートアップのログでは、日付と時刻がテキスト（VARCHAR）として記録されていました。インターバルを計算する必要が生じたとき、時間がそれぞれ異なる形式で記録されており、計算に時間のかかる正規化パースが必要で、パフォーマンスに悪影響を及ぼしました。