気になる？ - がるの健忘録

元ネタ
http://d.hatena.ne.jp/Sikushima/20101126/1290733753

えと…まず、このSQL

   SELECT *
   FROM 社員
   INNER JOIN 部課
   ON 社員.部課ID = 部課.ID

つまり「部課テーブルの情報を含めた、社員さんの情報一式とってこい」なわけですよね？やりたいことは。
これをOOPで一番ざっくり書くと、たぶんこうなるのですが。

$obj = new 社員全体を意味するクラス();
$list_all = $obj->get社員の情報一式();

「get社員の情報一式」の中で何をどうやっているのかはとりあえず隠蔽しておくんじゃないかなぁ、と。
そうすれば、何かがあったときに、それこそ最悪「インタフェースだけあわせてクラス総とっかえ」してもよいわけですし。

あぁ、ちなみにおいちゃんの一番の好みは、たぶんこんな感じのインタフェース。

$list_all = 社員さんを扱うutil::get社員の情報一式を無条件で();

戻り値は…MW的にはdata_clumpかなぁ。大まか「１インスタンスが１社員さん」なインスタンスの単純なvector的配列。
最もこんな「とりあえず全部の情報をとってきてから」なんていうメモリ負荷の高い処理、そもそも書きませんが B-p

で…以下の各プログラムが、「SQLのほうがOOPよりも優れいている、ってことを理解するためにサンプルとして付した、OOPなプログラミング」………らしい。
問題は「どこがなにがどのようにどうみたらどのへんが」OOPなのかが、ぜんぜんわからない orz

いち

   for(Object row社員 : 社員){
   for(Object row部課 : 部課){
   if(row社員.部課ID == row部課.ID){
   retSet.add(row社員);　　// LEFT JOIN のときには for の外に
   retSet.部課名 = row部課.部課名;
   }
   }
   }
   return retSet;

に

   for(Object row社員 : 社員){
   row部課 = 部課.seek(row社員.部課ID);
   if(row部課 != null){
   retSet.add(row社員);
   retSet.部課名 = row部課.部課名;
   }
   }
   return retSet;

(そもそも、いちとにがよ〜わからん。なんで似たようなloopを別々に書いてあるんだろ？つなげて使うのかなぁ？)

さん

   Object set社員 = 社員.sort(部課ID);
   Object set部課 = 部課.sort(ID);
   Object row部課 = set部課.current();

   for(Object row社員 : set社員){
   while(row社員.部課ID > row部課.ID){
   row部課 = set部課.nextRow();
   }
   if(row社員.部課ID == row部課.ID){
   retSet.add(row社員);　　// LEFT JOIN のときにはifの外に
   retSet.部課名 = row部課.部課名;
   }
   }
   return retSet;

よん

   Object setHashed部課 = 部課.hash(ID);

   for(Object row社員 : 社員){
   Object set部課 = setHashed部課.seek(row社員.部課ID.hash());
   for(Object row部課 : set部課){
   if(row社員.部課ID == row部課.ID){
   retSet.add(row社員);　　// LEFT JOIN のときには for の外に
   retSet.部課名 = row部課.部課名;
   }
   }
   }
   return retSet;

…うん、もし業務で「これがおぶぢぇくとしこうぷろぐらみんぐ、Da〜〜〜〜!!」とかいってこんなんしか出てこなかったら、絶望のあまり「OOPってなんて使えないんだ！！」って叫ぶかもしれない(苦笑
っつか。こんなもどき未満なものを提示されて「OOPが使えない」とか言われましても……… orz

あとついで。

http://d.hatena.ne.jp/Sikushima/20101124/1290571758

RDBMSを使いながら「SQLを使わない（単純なSQLだけを使う）方針」というのは、何と何をトレードオフしているのか？

CAP定理のうち、分割耐性(Partition Tolerance)とのトレードオフ。
JOINも副次問い合わせもつかわなければ、とりあえず「割合簡単に、横にサーバを広げる」分割耐性が手に入るので。
もっとも「ンならNoSQL使えばいいぢゃん」という話に対しては…とりあえず昨今思考している限りでは「そうだよねぇ」としか言えない(苦笑
雇う人のスキルセットとかお値段の高低くらいかなぁ、あと気になるところとしては*1。
実際問題「RDBでなければまずい」シーンは結構少なくて、だから本格的に出番が減ってるんじゃないかなぁ？

*1:でも「お安い連中」数やとっても、ねぇ(苦笑