JDK5事業拡大のため、新しい仲間を募集しています。→詳しくはこちらここでは、MySQLに関する事を書いていきます。新しく書いたものが上になるように並べてあります。新しくユーザ(権限)を追加するMySQLではOracleなどとデータベース・スキーマ・ユーザの考え方が違います。ユーザ情報は、mysqlデータベースという特別なデータベースにより管理されています。いくつかの権限に関するテーブルが用意されていてここにレコードを作成したりすることで、各種権限管理を行います。MySQL4以降では、このテーブルを直接いじることなくユーザ管理を行うコマンドが用意されました。他のデータベースではおなじみですね。MySQLではユーザを追加するときに、以下の情報を入力する必要があります。接続するときのパスワードこの中で少しやっかいなのがホスト名の設定です。MySQLではユーザ認証時、ユーザ名だけでなく「どのホストから接続されたユーザか」ということを認証の判断材料として利用します。これによって、ユーザ名だけによる認証よりも強固な可能になっています。全てのホストから接続可能で全てのデータベースにアクセスできるテスト用のユーザを作成してみましょう。部分が接続可能なデータベースおよびテーブル名です。全て接続可能という意味です。いう部分が、ユーザ名とホスト名の定義です。いうのがホスト名です。ワイルドカード形式なので、全てのホストから接続可能という意味です。これだけでは意外な落とし穴があります。localhostから接続できないのです。関する認証エントリが作成されているのでそちらの方が優先されるとあります。...よくわかりませんが、とりあえず次の一文を追加すればOKです。OPTION;このように、localhostに特化したGRANT文を発行します。これで、localhostも含めた全てのホストから接続可能なユーザが作成されました。外部に公開したマシンでこんなユーザは作らないで下さいね。通常、クライアントがINSERT文を発行するとサーバはそれに従ってレコードを挿入し、挿入が完了するとクライアントに処理を返します。他のスレッド(接続)がそのテーブルをロックしている場合にはそのロックが解除されるまで待つ必要があるためこのときクライアントは長時間待つことになります。DELAYED構文があります。これは、INSERT文を発行したときにそのレコードを即座に挿入するのでなくレコード挿入のための「ハンドラ」を生成しそのハンドラが保持するキューに挿入するレコードの情報を登録してすぐさまクライアントに処理を返します。以上のレコードがキューに登録されるとクライアントはキューに空きが出来るまで待機します。ハンドラは、テーブルが他のスレッドに使用されていないときを見計らってキューに登録されたレコードをテーブルに挿入します。型のテーブルに限られます。実際には、MyISAMテーブルでこの構文を使用しなければならない場面というのはそう多くありません。このテーブルではSELECT文とINSERT文の同時実行が可能だからです。INSERT文を発行したときに既にSELECT文が発行されていたとしてもMySQLサーバは待つこと無く即座にレコードを挿入できるのです。MySQL4.0から5.0へのデータ移行についてMySQL4.0から5.0にデータを移行するときの注意点があります。基本的に、MySQLはテーブルデータ内容をファイルで保持しているので同じバージョンのMySQL間ならばファイルをそのままコピーしてOKなのですがバージョンの異なるデータファイルをそのままコピーするとうまくいかない場合があります。具体的にはCHAR、VARCHAR型カラムの桁数が「1/3」になってしまいます。これはおそらく、最近のMySQLがCHAR桁数の解釈を変えたことに原因があると思います。MySQL5.0では、CHAR(10)に格納できる文字は「10バイト」ではなく「10文字(マルチバイト対応)」となっています。このため、MySQL4.0でCHAR(30)と宣言していたところがMySQL5.0ではCHAR(10)と解釈されてしまったようです。MySQL4.0から5.0にデータを移行するときには面倒ですがmysqldumpなどを使ってSQL文によるデータ挿入をしましょう。余談ですが、もしファイルをそのままコピーしてしまった場合でも既存データ内容が失われることはありません(確認済み)。TABLEで桁数を変更しておけばOKです。MySQL4.1での文字化けについてMySQL4.1では、文字コードの扱い方が以前までと大幅に異なっているようです。僕はJDBC経由での文字化けを解消するのにとても苦労しました。MySQL4.1.13(Linux版)で確認した、文字化けの解消法を記します。以下の記述を追加します(EUC-JPエンコーディング指定の場合)。記述はしてなかったのですが、どうもこれだとJDBC経由で文字化けしてしまいます。3.1.10で確認)。以前までは、JDBC接続文字列に文字エンコーディングの指定をしていたのですがMySQL4.1ではサーバ側の(.my.cnfの[client])設定を優先しているようです。その代わりに、JDBC接続文字列での文字エンコーディング指定は省略できるようになりました。いうか、指定しても無視されます。MySQLでの日付・時刻カラムの扱いMySQLはあらゆる面で、よりプログラマの視点に基づいた作りになっています。日付型のカラムに「1999-02-00」という値を格納することが許されています。OracleなどのDBでは、これらを格納しようとするとエラーが発生します。「00」という日にちは、現実の世界では有り得ませんがプログラムの世界では利便性の為に用いられることがあります。ある日付の正確な日付がわからないときなどに「2000-00-00」のように格納します。これは「2000年であることはわかっているが、正確な月日がわからない」ということを指します。関数は正常に働きませんMySQLでは、プログラムの一部としてDBを位置付けています。通常のプログラム言語では、日付の存在チェックなどは必ず行われています。よって、DB側でこれらのチェックを再度行う必要は無いという事です。チェックを行わないことで前述したような便利な使い方も可能になります。多言語・クロスプラットフォームこの前、Oracleを使ったプロジェクトで思わず問題が発生しました。旧暦では「2004-02-30」のような日付(←例えば)が正しい日付として存在しているらしいのですがOracleの日付型カラムにはこの値を格納することが出来ません。よって、このとき取った策は「全てのカラム型を文字列型に変更する」事でした。こんな馬鹿げた話があるでしょうか。旧暦も扱えないようなカラムを日付型と言っていいのでしょうか。MySQLは、あらゆる言語・あらゆるOSでの利用を想定しています。これは、多言語・クロスプラットフォームの現代では当り前の考え方です。範囲を取ることが出来ます。これも、利便性の為です。複数バージョンのMySQLを同一マシンから動かすサーバ上のMySQLをバージョンアップするときなど、必要不可欠になるのがこの作業です。現行のMySQLを動かしたまま、新バージョンのMySQLを動作させることが目標です。