2010/07/21

MySQLのSQL_MODEと日付型への値の挿入 その3

その1その2と、かなりどうでもいい内容について、無駄に検証してきたわけで、
今回はそのまとめにする。

ここまででわかったことをまとめると

MySQLにとって「実在しない日」には4パターンある。



1.「2010-02-32」 普通に実在しないパターン
日付型には格納できず、「0000-00-00」に変換される。

2.「2010-02-31」 月と日を組み合わせることで初めて実在しないとわかるパターン
「ALLOW_INVALID_DATES」を設定している場合のみ格納できる。
設定していない場合は「0000-00-00」に変換される。

3.「0000-00-00」 0のみで構成されたパターン
通常は格納可能。
「NO_ZERO_DATE」を設定している場合は「0000-00-00」に変換される。

4.「2010-01-00」 日または月に0があるパターン
通常は格納可能。
「NO_ZERO_IN_DATE」を設定している場合は「0000-00-00」に変換される。


いずれの場合も「0000-00-00」に変換される時に
通常は変換されたまま格納されるが、後ろではWarningが発生している。
さらに「STRICTモード」だとエラーになり、格納もできない。
それだけのことだ。

実験する前はそれぞれ複雑に絡み合っているかと思っていたが、
試してみると以外に単純明快だった。
いやはや、マニュアルどおりの結論に至るのに無駄に回り道をしてしまった気がする。


余談

今回のテーマは「値の挿入」に絞っているのであまり深くは触れないが、
この検証をしている過程で興味深いネタをみつけてしまった。
それは実在しない日付との「比較」である。

現段階でわかっていること。
・どのケースも「比較は可能である」。
・「0000-00-00」はどの日付よりも小さい。
・「2010-02-00」は「2010-01-31」よりも後ろで、「2010-02-01」よりも前。
・レコードにある日付と「2010-02-32」を比較すると、クエリキャッシュが使われない。
 (おそらく文字列変換が起こっている。)


このネタは掘り下げればかなりの深さになるに違いないので、またの機会にしておこうと思う。

0 件のコメント:

コメントを投稿

注: コメントを投稿できるのは、このブログのメンバーだけです。