SQLiteは、数値列への非数値の挿入を受け入れなければ、あまり役に立たないでしょうか？

SQLiteでは、次のステートメントが成功し、文字列がSALARYタイプの列に挿入/更新されますINTEGER。

update employee set salary='TOO MUCH' where emp_id=1;

ゼロは挿入/更新されませんが、実際の"TOO MUCH"文字列なので、これは自動型変換に関するものではないことに注意してください。

FAQは述べています：

これは機能であり、バグではありません。SQLiteは動的型付けを使用します。データ型の制約は適用されません。任意のタイプのデータを（通常は）任意の列に挿入できます。任意の長さの文字列を整数列に入れたり、浮動小数点数をブール列に入れたり、日付を文字列に入れたりできます。CREATE TABLEコマンドで列に割り当てるデータ型は、その列に入れることができるデータを制限しません。すべての列は、任意の長さの文字列を保持できます。（例外が1つあります。INTEGERPRIMARY KEYタイプの列は64ビットの符号付き整数しか保持できません。整数以外のものをINTEGER PRIMARY KEY列に挿入しようとすると、エラーが発生します。）

したがって、この動作は明らかに意図的なものですが、 SQLiteがこの動作をするのはなぜでしょうか。私が知っている他のほとんどのSQLデータベースはまったく異なる動作をするため、非数値文字列を挿入しようとすると、エラーが発生するか、文字列0に変換されます。数値列。

• SQLiteライブラリは、この振る舞いなしではあまり役に立ちませんか？

• これは、ライブラリを小さく高速に保つために設計されたものですか？

• 文字列を数値列に挿入しようとするとエラーが発生するために、SQLiteライブラリは大幅に遅くなったり大きくなったりしますか？

いいえ、特に動的型付けには、より多くの記憶域と処理時間の両方が必要です。特に、型の親和性が追加されるため、プログラマーは自由に無視できる優先型になります。これは、実際のトレードオフコストを伴う意図的な機能です。これらのコストは、SQLiteターゲットのユースケースでは事実上無視できますが、それでも存在します。

このような機能を使用できるようにすることに慣れていないため、そのような機能の有用性はわかりにくいものです。その欠如に対する回避策は、あなたにとってより自然に感じられるでしょう。以前の経験から、それは決して他にはならないINTEGERフィールドと考えていますが、SQLiteはそれを任意のタイプのフィールドと見なしますが、おそらくほとんど整数を含みます。おそらくそれは、主に米国でビジネスを行っている会社の郵便番号であるが、カナダの顧客は少数です。ユーザーが整数アフィニティを指定できるようにすると、すべての行で文字列を文字列にするよりも多くのスペースを節約できますが、それでもそのオプションは提供されます。