DBの最近のブログ記事

イヌ派かネコ派かと聞かれたら、ネコ派なんですが、イヌも嫌いじゃあないです。
ですが、MySQL派かPostgreSQL派かと聞かれたら、「MySQLがキライなのでPostgreSQL派です。」と答えてしまいます。

さて、ハッシュ関数がDB側で使えるとユーザー認証のときとか便利なので使っちゃいます。
で、PostgreSQLでハッシュ関数を使うには、別途関数登録的なSQLをインストールして、それを対象データベースに流してやる必要があります。

PostgreSQLにはオリジナルのCOPYコマンドというのがあって、これがCSVとかTSVの入出力で便利。

文法の詳細はこれ読んでちょ。
http://www.postgresql.jp/document/pg833doc/html/sql-copy.html

出力でもっともシンプルな形だと

postgres=# copy hoges to 'C:/tmp/hoge_export.csv';

のような感じ。

もしかしたらあなたは

ERROR:  character 0xe28094 of encoding "UTF8" has no equivalent in "SJIS"

とかいわれるかもしれない。
そんなときは

postgres=# \encoding SJIS

とやっておくとうまくいくかもしれない。

僕に選択権のある限り、MySQLは二度と採用しません。断然PostgreSQLです。

わけのわからん文字コードとの格闘とか、形だけのViewとか、しょーもないindexとか、もうたくさんです。いや、僕が無知なだけかもしれないってのはあると思ってますよ？けど、そんなわけわからん仕様に付き合うために勉強するんだったら他のこと勉強しますよ。それにPostgreSQLでそーいったトラブルにあったことないもん。
MySQLは検索が早いとかもう昔の話しだし！
MySQLのおかげで帰れない日がどんだけあったことか！

PostgreSQL!　PostgreSQL!

日本人のみんな！PostgreSQLを使おう！

誰か僕にMySQLとPostgreSQLの２択があるときにMySQLを選ぶ理由があったら教えてください。
XAMPPに入ってるから、とかInstantrailsに入ってるからとかはナシで。実績があるからってのも信用しないので。できれば、PostgreSQLでやろうと思ったけど、PostgreSQLのこれがだめだったからMySQLにしました、的なのがあるとうれしいです。
つまり、機能面とか開発効率面とか、そういうプロダクト自信の長所で推してくれるとうれぴーです。

２００８年７月１９日時点でMySQL＜＜＜＜＜＜＜＜＜＜PostgreSQL。

あー、よっぱらったー

my.iniあたりにこんな記述を入れると幸せになれるかも。

==============
[mysqld]
default-character-set = utf8
skip-character-set-client-handshake
character-set-server = utf8
collation-server = utf8_general_ci
init-connect = SET NAMES utf8
==============

あ、決してDerbyである程度のデータ量になると、重すぎてやっぱ話になんないから、デフォルトのままチューニングもなにもしないであきらめて、MySQLにしてみたわけではないので。一応。念のため。

エクスポートは、規定のプロシージャを使う。
書式は下記のとおり。
========-
SYSCS_UTIL.SYSCS_EXPORT_TABLE (IN SCHEMANAME VARCHAR(128),
IN TABLENAME VARCHAR(128), IN FILENAME VARCHAR(32672),
IN COLUMNDELIMITER CHAR(1), IN CHARACTERDELIMITER CHAR(1),
IN CODESET VARCHAR(128))
========

1つ目：スキーマ名。たぶんたいがいの場合において指定はいらない。
2つ目：テーブル名。指定してください。ここ指定しないと即エラーっす。
3つ目：ファイル名。エクスポートするファイル名を含めたパスを書きます。ここ指定しないと即エラーっす。存在するファイル名を指定してもエラーっす。パスなしのファイル名のみはカレントに出力される。
4つ目：カラムのデリミター。指定なしはカンマ","。
5つ目：カラムの中身が文字のときのくくり文字。カラムAに「あいうえお」って入ってたら,"あいうえお",みたいなの。指定なしはダブルクォーテーション"""。
6つ目：文字コード。指定なしはDerbyが動いているJVMの文字コードと同じ。

たぶんたいがいの場合において2番目と3番目だけ指定しときゃいいんじゃないでしょか。
※指定なしは、nullを入れる。

で、プロシージャ呼び出しなんでcallを使ってください。
こんな感じすね。

例）
call SYSCS_UTIL.SYSCS_EXPORT_TABLE (null,'HOGE','C:\\hoge.exp',null,null,null);

詳細はここ。
http://db.apache.org/derby/docs/dev/ref/ref-single.html#rrefexportproc

あと、これはバグに近いと思うんだけど、少なくとも10.3.1まではプロシージャ名が正しくても引数の数とか間違えると、まるでプロシージャ自体が存在しない風のエラーがでる。
========
ERROR 42Y03: 'SYSCS_UTIL.SYSCS_EXPORT_TABLE' is not recognized as a function or procedure.
========
ので要注意。

インポートはまた今度。

そんな最近の話じゃないんだけど、JDK6にはJavaで作られているRDBMSであるDerbyがデフォルトで組み込まれている。
※JavaDBという表記になっていることもある。
http://db.apache.org/derby/

JDKデフォルトかつ約２Ｍという軽量構成なので使い道もいろいろあるんだろうけど、筆者が使ってみようかなと思ったのはプロトタイプ開発のときとかにサクッと使えるイメージがあったからだ。

とにかく使ってみないとよくわからないので、とりあえず使ってみる。
で、IDEが大好きな筆者は当然Elipseと絡ませて使っていく。
※ちなみにJDK6をインストールすると、なぜかDerbyだけはデフォルトでC:\Program Files\Sun\JavaDBにインストールされた。

まずDerbyのEclipseプラグインをダウンロード。
http://db.apache.org/derby/derby_downloads.html#How+to+build+Derby

なぜか、2008/04/29時点の最新版である10.4.1.3 Releaseのcoreプラグインがリンク切れしていたので、一個まえのやつを使った。
derby_core_plugin_10.3.2.599110.zip
derby_ui_plugin_1.1.1.zip

この２つをEclipseのインストールフォルダに解凍。で、Eclipse起動。起動してたら再起動。
これで準備完了。

適当なプロジェクトを作って、プロジェクトルートを右クリックすると「Apache Derby」というのがコンテキストに現れる。
で、「Start Derby Network Server」をクリック。すると以下のメッセージが表示され起動する。
===============
DRDA_SecurityInstalled.I
Apache Derby Network Server - 2008-04-29 04:52:45.812 GMT に 10.3.2.1 - (599110) が開始され、ポート 1527 で接続を受け入れる準備ができました。
===============

で、次はApache Derby>ij(Interactive SQL)をクリック
SQL入力のプロンプトがコンソールに表示される。

ij> connect 'jdbc:derby://localhost/db;create=true';

と入力すると音もなくDBが作成されて、かつそのDBに接続される。
localhostの次に書いてある「db」は任意の値でこれがDB名となる。
作成が完了すると、DB名のフォルダ（この場合「db」）がプロジェクトルート直下に作成される。
この下はデータファイルとかが格納されるっぽいく、基本的にはいじらないっぽい。

2回目からは
ij> connect 'jdbc:derby://localhost/db;create=true';
でも
ij> connect 'jdbc:derby://localhost/db;create=false';
でも
ij> connect 'jdbc:derby://localhost/db;';
でもいい。※create=trueはなかったときだけ作る

ここまでで、適当なDBを作ってみた人向けに先にお知らせ。
drop database的なものはないので、DB落とすときはフォルダをガッと消してください。
※Eclipse起動してると消えないかも
ということは、フォルダごとコピーとればとりあえずバックアップってことになる。

その辺のこととか、細かいことはここに書いてある。
http://db.apache.org/derby/docs/dev/devguide/

で、とりあえずパッとでてくるSQLを打ってみる

==========
ij> show tables;
TABLE_SCHEM |TABLE_NAME |REMARKS
------------------------------------------------------------------------
SYS |SYSALIASES |
SYS |SYSCHECKS |
SYS |SYSCOLPERMS |
SYS |SYSCOLUMNS |
～中略～
SYS |SYSTABLES |
SYS |SYSTRIGGERS |
SYS |SYSVIEWS |
SYSIBM |SYSDUMMY1 |

19 rows selected
==========

SYS系のテーブルがズラーっとでてくる。
最後のSYSDUMMYはスキーマがSYSIBMになっているのは、Derbyは元々IBMからapacheに寄贈された経緯があるから。

この辺のテーブルは操作しようとしても、見つからないって言われる。
==========
ij> select * from sysdummy1;
ERROR 42X05: Table/View 'SYSDUMMY1' does not exist.
==========

だったら出すなよ気になるじゃん。と思うけど、まあいいや。
追記：デフォルトだとAPPユーザー扱いになるから、sysdummy1だと見えないんですね。。select * from sysibm.sysdummy1;で見えます。。

テーブルを作ってみよう。
===========
ij> create table test (a integer, b varchar(255));
0 rows inserted/updated/deleted

ij> show tables;
TABLE_SCHEM |TABLE_NAME |REMARKS
------------------------------------------------------------------------
SYS |SYSALIASES |
SYS |SYSCHECKS |
SYSIBM |SYSDUMMY1 |
APP |TEST |

20 rows selected
===========
1個追加された。
スキーマがAPPとなっているが、デフォルトはAPPが割り当てられる。
と、ここでユーザー認証とかどうなってんだ？ということに気づいた。今回の目的からすると、まあ、どうでもいいんだけど、一応調べた。
そしたら、認証以外でも非常に参考になるサイトを見つけたので後はこちらをご覧ください。
http://www.oklab.org/derby.xhtml

追記：
Derbyのドキュメントについて、日本語verがあった
http://db.apache.org/derby/docs/dev/ja_JP/getstart/
が英語のそれと比べて量が全然違います。

けっこうこういう日本語版があるけど英語版と情報量が違うのってよくあることなんで、なるべく英語のほうを見ることをお勧めします。
余計なお世話かも知れないですが、こんな感じで日英両方あったらなるべく英語のほう見てわからなければ日本語みる、みたいなことをやると英語のトレーニングになるし、情報量の違いにも気づきやすくなるし、いいと思います。
ITは米国先導なので情報もあちらの方がたくさんあります。WEB検索にしても日本語じゃみつからない解法とかが英語圏に範囲を広げるとめちゃくちゃあっさり見つかることが本当によくあります。
この業界で人より早く技術を身につけようと思ったら、英語の読みができるようにしておくことは、必須といわないまでも非常に有効な手段だと思います。逆に言えば、英語をかわしながら技術を身につけていくのは、光の玉なしでゾーマに臨むようなもんだと思ってます。
ということでLet's try!