好きな人は好きなOracleですが、自分は好きではない(管理者としては面倒なイメージがある + 馬鹿みたいに「高い」ので)。       
しかし、私が一番好きな、BerkeleyDBを手に入れてしまった!  
どうなる、BDB?           
Oracleに飼い殺しにされないかが不安です。    
       
世の中では、LAMPといい、Linux + Apache + MySQL + Perlが、hatenaやmixiなどの隆盛により、注目されている。           
大した用途ではないが、他のエンジニアと協業する時に、MySQLを使ったことがあるが、自分サイトの為には使わない。    
 
ただ、MySQLの下層には確かBelekeyDBがいる筈で、そのBerkeleyDBには非常にお世話になっている。  
語弊を恐れず言えば、BerkeleyDBは最速のデータベースなのだ。           
そもそもBerleyDBは、SQLで値を得るのではなく、キー→値という構造のデータベースだ。         
Perlにおいては、デフォルトで付いてくるDB_File.pmを通じて、ハッシュをファイルとして保持して使うのに役立つ。    
SQL文を解釈する別の巨大サービスが動いているSQLデータベースに比べると、そもそもデータの取得に必要なステップが全然少ない&別プロセスを介す必要がないので、当然速いし、リソースもより少なくてよい。
携帯向け組み込み用DBとして使われるということからも、コンパクトさが分ると思う。

私は、会社を通じてする仕事ではSQL DBを使うことはあるが、自分一人でする仕事は、
テキストファイル + Berkeley DB + BER圧縮転置ファイル
で全てをこなしている。
速度の追求とサーバーマシンの最適化を図るのなら、SQL DBは大きなボトルネックになるので、それに頼らない構成を作れることが必要になる。

SQLという言語は、色々な人が使いやすいという意味で、複数の人と共同で働く環境において、共通言語としての価値はあるけれども、その利点の反面、データへのアクセスという意味では、必ずしも最適な解ではないことも多いということを、常に頭に入れて開発をするのもありだと思う。何でもかんでもinsertして、それに対してselectするという高コストな発想しかないのと、第一候補にBerkeley DBがあるのとでは、できることに随分と違いが出る。SQL DBはデータに対する高度なコントロールを提供してくれるが、アクセス速度に対する高度なコントロールを得るにはBerkeley DBの方が向いている。それに加えて、BER圧縮転置インデックスも自力で構成できれば、速度がボトルネックになる問題には、大概最適解を見つけることが出来るだろう。

<=次記事2006/02/16 共有タグのバグ修正 =>前記事2006/02/14 お勧めリンク集リストの追加等 大分類が「Berkeley DB」の記事 記事全て