TOP＞サーバ構築・運用＞ 更新時における日付時刻の記録
徹底比較!! PostgreSQL vs MySQLパート2
徹底比較!! PostgreSQL vs MySQLパート2

第１回：同じようで違うデータ型
 著者：NTTデータ   藤塚 勤也   2007/4/2
前のページ  1  2  3
更新時における日付時刻の記録

   ではここで、この挿入したレコードの「COL02」と「COL03」を更新するため、以下のようなUPDATE文を実行したとします。
UPDATE TABLE01 SET COL02 = '9999', COL03 ='9999' WHERE COL01='1000'

   この時も「COL04」には、この更新を行った時の日付時刻を記録したいとします。ところが、PostgreSQLの「COL04」には、更新した日付時刻は記録されず挿入時の値そのままで変更されません。PostgreSQLは、デフォルト制約を使用してこの仕組みを実現しているため、あくまでも「COL04」内に日付時刻が自動的に記録されるのは、レコードの挿入時のみに限定されるからです。この更新をPostgreSQLにて行う場合は、「COL04」にその時の日付時刻を明示する必要があり、それは以下のようなUPDATE文になります。

UPDATE TABLE01

SET COL02 = '9999', COL03 ='9999',COL04=now() WHERE COL01='1000'

   この例では、現在の日付時刻の値を生成する関数「now()」を使用して、「COL04」の値を更新しています。

   一方MySQLの場合は、期待通りに「COL04」に更新した日付時刻が記録されます。MySQLのtimestamp型には、INSERTやUPDATEによって、現在の日付時刻を自動で記録する機能があるのです。この機能は、デフォルト制約の機能とは異なり、MySQL特有の機能です。

   もし、この機能を使用したアプリケーションを他のRDBMS、例えばPostgreSQLへ適用した場合、期待とは異なる結果を生みます。さらに問題なのは、アプリケーションが使用するSQL文自体は正常動作し、格納されたデータを確認することによってはじめて結果が異なることが判明するため、問題点の検出に時間がかかる可能性があります。
不正な日付の入力

   続いて、日付型のカラムにデータを挿入する場合の動作を比較して見ます。例えば、テーブル「TABLE02」のDATE型カラム「COL01」へデータを挿入する場合、PostgreSQL、MySQLどちらの場合も以下のINSERT文で問題ありません。

INSERT INTO TABLE02 (COL01) VALUES ('2004-9-10')

   例えば、このINSERT文を使用するアプリケーションが、挿入する日付データをユーザに入力してもらうものだとします。仮にユーザが日付データの入力を間違えて、「2004-9-31」といった値を挿入したとしたらどうなるでしょうか。

INSERT INTO TABLE02 (COL01) VALUES ('2004-9-31')

   PoatgreSQLの場合、このINSERT文はエラーとなります。9月には31日が存在しないこと、つまり日付としての正当性のチェックをしているのです。よって、アプリケーションは、このエラーからユーザの入力に誤りがあったことを検出できます。

   ところが、MySQLの場合は「SQL Modes」と呼ぶMySQLサーバの設定状態によって、このINSERT文の動作が異なります。ここでは、「SQL Modes」についての説明は省略しますが、PostgreSQLの動作と同等の設定もありますし、異なる動作をする設定もあります。この異なる動作をする設定にすると、存在しない日付の値のINSERT文が正常終了してしまいます。

   それは、この「SQL Modes」のMySQLは、年は「'1000'-'9999'」、月は「'00'-'12'」日は「'00'-'31'」といった範囲チェックのみをしているためです。さらに、この日付データに「2004-9-40」といったデータを挿入しようとしてもエラーにならず、データベース内には「0000-00-00」といった値が格納されてしまいます。

   MySQLにてこの状況を避ける必要がある場合は、「SQL Modes」を変更するか、日付データを挿入する際アプリケーションにて日付としての正当性をチェックした後、INSERT文を実行する必要があります。このように、PostgreSQLとMySQLでは、日付データのチェック機能の違いによりSQL文の実行結果に違いが発生します。この動作の違いは、PostgreSQLとMySQLどちらを使用するかによって、アプリケーションの設計に大きく影響を与えるので注意が必要です。
同じようでも違うデータ型

   以上、説明してきたように、PostgreSQLとMySQLのデータ型は同じようで違いがあります。特に、名称は同じでも保存領域が異なったりしますので、注意が必要です。
前のページ  1  2  3

NTTデータ 藤塚 勤也
 著者プロフィール
株式会社NTTデータ   藤塚 勤也
基盤システム事業本部 オープンソース開発センタ シニアスペシャリスト。
日本タンデムコンピューターズ（現日本HP）を経て、2003年よりNTTデータにてOSS分野に参画。日頃はオリジナルOSSの開発や、OSSを用いたシステム構築への技術支援に従事。「RDBMS解剖学」（翔泳社）を共著。
INDEX
第1回：同じようで違うデータ型
  連載で扱うバージョン
  文字データ型について
更新時における日付時刻の記録