(10.99、0.99 など) のような 10 進形式のユーザー クレジットを保存する必要があります。今のところ、列フィールドを varchar(100) としています。
varchar の代わりに decimal を使用するとどうなりますか。パフォーマンスが向上しますか??
簡単に言えば、いいえ、パフォーマンスが低下します。
より長い答え: VARCHAR フィールドは可変長です。つまり、データベース ブロックのフォーマットでは、そこに入力されるデータのサイズを事前に考慮することはできません。確かに、フィールドの最大長はありますが、それ以外はもっと悪いです。
一方、VARCHAR を読み取り、それを浮動小数点型に適合するように解釈するにはコストがかかります。そして、それは新しい問題の可能性をもたらします。「11.99」を占めるすべての小数を取得してみてください。VARCHAR "11.99" != "11.990" であるため、小数点以下の桁数を正しく設定してください。
そして、インデックス作成があります。通常、10 進数フィールドにインデックスを作成する人はいませんが、万一、VARCHAR フィールドのインデックスを作成するには、より多くのスペースが必要になります。
全体として、不特定のフィールド タイプに何かを保存するのは得策ではありません。DB 構造では、通常、できるだけ具体的にすることがベスト プラクティスと見なされます。
数値のように見えるものを文字列として保存したい場合があります。たとえば、米国では 5 桁の郵便番号は数字によく似ています。ただし、先行ゼロは重要です。したがって、それらは実際には数字ではなくラベルです。これは簡単です。郵便番号は文字列として格納する必要があります。
他のほとんどの場合、数値を数値として格納します。「ユーザークレジット」と呼ばれるフィールドは、フィールドで足し算や引き算をしていることを示唆しています。ですから、これも仕方のないことです。数字のように見え、数字のように歩き、数字のように鳴く。. . 数値として保存します。
MySQL は、文字列の数値部分の後に不要な文字が含まれている場合でも、文字列を自動的に数値に変換するため、選択を少し混乱させます。
2 番目の小数点を正確に格納する場合DECIMAL(5,2)
は、浮動小数点型 ( など) ではなく固定小数点データ型 ( など) を使用しfloat
ます。