第9回　保存先の変更 その3 - OOP講座

保存先の変更 後編

前回はDBハンドルについて詳しくやりました。DBハンドルまでしかたどり着けなかった、と書いても本質は一緒ですが多分ニュアンスがちがいます。
そんな名誉を挽回すべく、今回はSQL文回りについて少し細かくやっていきたいと思います。

…という景気の良い(?)出だしの、のっけからで大変に恐縮ではあるのですが。 現実問題として、このあたりから、第七回で書いた「深くて暗くて乗り越えにくい壁」が出てきます。
以前にも書いたのですが、SQLとオブジェクト指向って、根っこにあるパラダイムに大分と差違があるんですね。
なので、それを無理にすりあわせようとすると、どうしてもどちらかに変なズレが発生します。

とはいえ、「だからやりません」ってのも少々如何なものかと思いますので、無理が出ない程度に最低限までは親和させてみたいと思っています。

先に書いておきますと、「割合にがっつり親和させようとした」一例が、現在、割とあちこちで出ているORMになります。
ただ、ある程度以上厄介な(とはいっても常識的な範疇内の)リレーションが張られているテーブルに対するアクセスの、裏側で流れているSQLを見ている限り…正直、筆者的にはお世辞にも「うまくいっている」ようには見えないんですよね。

ORMが好きな人も嫌いな人も、一度はちゃんと「裏側でどんなSQLが流れているのか」は意識をしておいたほうがよいです。
どんなSQLが流れているか、そのメリットデメリットを十分に考察した上でなら、ORMを毒とするも薬とするも、ある程度自在だと思います。

とまぁ、のっけから軽く怖い話をしながら。
「全方位かつ全業務に向けてあらゆる可能性を考慮した副作用のない万能薬」なんて考えても切ないだけですので、一端「今回の掲示板に必要なもの」程度に対する考察をしてみましょう。
欲しいものは概ね

• 掲示板メッセージの主キーのリスト
• １主キーに対する情報一式

の２つになります。 では、ここを前提に少しインタフェースを切ってみましょう。

list 1

大体こんなイメージではないでしょうか。
get掲示板メッセージList にあるvectorというのは「hashではない、単純な配列」を連想してください。PHP的には普通に arrayですね。昇順の数字が添え字になっていると思っていただければ。