SQLの暗黙の型変換はワナがいっぱい

補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2009年9月24日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、SQLにおいて「暗黙の型変換」を使うべきでない理由として、具体的な「ワナ」をいくつか紹介します。 数値項目に対するSQLインジェクション対策のまとめにて説明したように、RDBの数値型の列に対してSQLインジェクション対策をする方法として、以下の三種類が知られています。 バインド機構を用いる パラメータの数値としての妥当性確認を行う パラメータを文字列リテラルとしてエスケープする このうち、方法3を使うべきでない説明の補足です。具体的には、方法3には、「暗黙の型変換」が発生しますが、それが思わ

[kjtec]

数値型の値を、文字列リテラルとしてエスケープするSQLインジェクションの是非について

[chanpon0]

castまでする必要があるか。。

[katoken12]

“この場合、列employeeidの方が数値型に変換されながら検索が実行されます。これはパフォーマンスの低下をもらたらします。インデックスが使用できないからです。”

[hnw]

MySQL5.5.3でstrtodの実装が修正されており、十進20桁の例の挙動が変わっています。結論とは無関係ですが念のため。 http://d.hatena.ne.jp/hnw/20120408

[secseek]

暗黙の型変換に関する検証記事です。結論として「SQLリファレンスを通読する（冗談です）」と書かれていますが、ここまでややこしい内容だと、冗談とも思えません。

[oppara]

: SQLの暗黙の型変換はワナがいっぱい - 徳丸浩の日記(2009-09-24)

[deep_one]

そもそも暗黙の変換とか使わないに越したことはないんですけどね。仕様が変わったりすると怖いし。

[prisira]

暗黙の型変換を推奨しようとする同僚に見せる用

[mumincacao]

型のゆるい言語からはじめたひとはこのあたりの自動変換を『よきにはからってくれるからいいじゃない』ですませてなかなか理解してくれない気がするのです（´・ω・｀；【みかん

[Katsuji]

パフォーマンスで痛い目見たことがあるので再度勉強しなおす

[faerie]

あとでよむ

[nilnil]

SQLの暗黙の型変換による完全性と可用性低下の問題。プログラミング言語中で動的生成されることもあるから、SQL文のlintみたいなのってできないのかな。RDBとのI/F部分hookしてモニタするくらいか?

[katzchang]

パローマンス低下、精度で切り捨てとか。

[larker]

SQLの「暗黙の型変換」

[IwamotoTakashi]

「例えば、暗黙の型変換を避ける」

[ockeghem]

id:daffy 他のDBではそうなりません。参考→http://d.hatena.ne.jp/teracc/20090605#1244210244