SQLって便利っちゃー便利。まぁそんなことは今更gdgd言わなくてもいい。
「理屈通りに作れる」ことに美しさを感じる人には、たまらなく嬉しいものだろう。まぁ現実のシステムだと、なかなか理屈通りに行かなかったり、理屈を曲げないと遅かったりするんで、実務家はイライラするんだろうけど。そんなイライラもあってか、つい
に「うんうん」と思ってしまう。
RDBの外見って美しい。つーか、SQLは美しい。まぁPL/Iっぽいっつーか、COBOLっぽい臭いが漂うのがあまり好きになれないけど、背景にある理論は美しい。そんなところが好きな人は多いんじゃないかと思う。
じゃあ実装する方はどうかと言えば、なかなか微妙だ。今まで2つSQL絡みの実装に関わったことがあって、そのうち1つはフルスクラッチで作ったんだけど、なかなか難物だった。私の実装が稚拙なせいってのもあるんだろうけど、JOINとかすげー面倒臭いの。inner joinだけだったら、まぁそんなに大変じゃないんだけど、他のJOINは面倒臭かった。メモリー使いまくっても良いとか速度を気にしないとかだったらそれ程は面倒臭くもないんだけど、「軽く」とか思うと面倒っちぃ。富豪にやりゃーいいんだろうけど、貧乏なもんでｗ SQLの外見は綺麗だけど、その代わり中が大変だから、
白鳥の水かき
みたいなもんだ。で、油断してるとボロが出る。富豪に作りゃボロも結構表に出ないんだろうけど。
逆にSQLを書く方をやってみると、自分じゃあJOINはinner join以外まず使わない。つーか、なまじ中身を知ってるから、inner join以外のJOINは「使ったら負けかな」と思っているので使わない。さらに言えば、ほとんどのJOINは「コードテーブルのlookup」くらいにしか使ってない。
JOINがそんなもんだから、副問い合わせとか「なんですか？」のレベル。処理系は書けても、そのコードは書けねーとゆー。つまり、私にとってSQLやRDBって「関係演算がどーたら」なんて高等なもんじゃなくて、
多重インデクスと自動コードテーブル参照
でしかない。SQLで凄いことが書ける人を見るとカコイーって思うんだけど、自分でやりたいとは思わないし、そもそもそのコード読めない。いや、人間パーザになれば読めないこともないけど、ストレートに頭に入って来ないから、読めないも同然。
割り切って使う分にはSQLって便利で柔軟だなーと思うし、だからこそ「SQLの使えるサーチエンジン」なんて変なものを実装しようとしたんだけど、凄く複雑なことが出来ることまでは出来なくていーなと思う。
それとは別にORマッパっぽいものを書いてると、あんまり複雑なSQLが書きたいと思わなくなってしまう。SQLの処理系がやってるようなことを、ついアプリケーションの方で頑張る方向になってしまう。SQL習い初めの頃はそんなダサダサなことをやるのは恥ずかしいとか思って、一生懸命「ちゃんとしたSQL」を書こうとしたりしてたんだけど、今はなんか「ダサくてもいーじゃん」とか思ってしまう。いろいろ楽だし。とか思うと、別に「SQLの使えるRDB」である必要を感じなかったりする。むしろ、「SQLなんてどーでもいーから、オブジェクト永続化だけ出来りゃいーよ」と思う。
てのは個人的な感想だけど、同じようなことを思う人は少なくないと思う。RDBって便利だと思うけど、「SQLの技巧」みたいなことが出来る必要性ってあまり感じないし、「関係演算」も凄いことが出来なくてもいい。確かにデータベースの諸々を宣言的かつ特定の言語に依存せずに出来るのは悪いことではないけど、「特定の言語」がSQLになっただけとも言えるし。
などなど思っていると、時代も時代だし、普通のウェブサービスやらたいていのトランザクション処理にとっては、
RDBもSQLもいらないんじゃねーの
的な意見は、まぁ妥当なんじゃないかと思う。SQLよりもORマッパの時代だろとか。
まぁ、ストレージ回りはもっと頑張る余地はありそうだなと思う。FLOSSでSQLの使えないデータベースっぽいものって、トランザクションも満足に使えなかったりというのが悲しいよね。余裕があれば古いコード引っぱり出していじりたいなって気がするけど、今は余裕ないしな。他人様の目に触れさせる程のコードでもなし。
って、結局リンク先の記事と大差ないこと言ってるなぁ…