データベース
リファクタリングとは
大きいものを小さくする
小さいものから大きいものを組み立てる
小さいものに名前をつけて抽象化する
select * from sales
where deleted_at is null order by amount desc limit 10
SQLには、リファクタリングに用いられる3つの用途で
コマンドは打てない
別言語でスクリプトは書けるけど、SQLそのものを抽象化出来ない。
Sales.active.top(n)
アセンブラ→C,Pascal→OOP,Functional
抽象化能力を高めるために言語は開発された
SQLに抽象化能力はない
より高次元の抽象化能力を有するDBはDBI,ORM,ModernORMなどがある。
SQLはアセンブラの一種
抽象化能力を持たないSQLを補完するのが、ORMやModernORM
Rails3では、メソッドチェーンによりDB検索の条件を指定出来る
queryが返ってくる
query = Member.where('age >= ?', val)
ORMによって、名称が変わってくる。
Method Call vs Query Op
Rails3ではqueryオブジェクトを操作する
メソッドチェーンに目がいきがちだが、
あくまでもqueryオブジェクトを操作する事が目的
従来なら文字列のみで条件を指定していたのに
対し、Rails3なら条件をオブジェクトに格納し、
オブジェクトに対して演算を行う事が出来る
オブジェクトを組み合わせる事によって、
条件を決める事が出来る
オブジェクトそのものを配列として利用し、
ブロックを使ってイテレータを働かす事も出来る
メソッドにオブジェクトを格納するのではなく、
オブジェクトに対してメソッドで操作する
(やっている事は一応一緒)
##Data Mapper
class Sales
def self.active
where(:deleted_at=>nil)
end
end
集合演算が可能なので、必ずしも
関数型言語で言うところの、関数の部分適用
Query can abstract SQL.
View層のcache
ビューでの操作をするのはMVCに違反している
push-style vs pull-style
キャッシュの存在をコントローラーで確認すべし
オブジェクトを作成するだけでは、DBにアクセスしない
ビュー層に一切変更はない。
MVCとフラグメントは相性が悪い(push-style vs pull style)
が、クエリオブジェクトの操作により、解決する
SQLの発行の際に、別データも取っておく(but変更に弱い)
datamapping 必要なデータを過不足なく取得する必要がある
関連データを指定してやる必要がある
eagar loadingを使うと、必要なデータをいちいち取り揃える必要はない
(Rails2,3では無理)
Ruby ⇔ AST ⇔ SQL
ASTをせば、Rubyの書き方で、SQLを発行出来る
rubyの書き方をSQLが読み取ってくれる(逆も然り）
