データベース

フラットファイルでも

データベースを使わない運用方法も提供。フラットファイルにすべて保存。データベースのラッパークラスをすげ替えてフラットファイルに対応。全文検索など、不向きなことには独自のインデックスを用意するか、何も返さない。

DBにゆとりを

リレーション用のキー（投稿ID）列、キーの列、値の列…の汎用テーブルを用意。

キーを自由につけて、運用中にでもデータ追加・削除。投稿ごとに列名が揃っていなくてもいい。

管理者による改造のために。

キーを削除するときは値を未定義値にする。存在しないキーを呼んだときは未定義値が返る。

DELETE文に相当するので、UPDATE文とは別の、削除だけのSQLで。

モデル層オブジェクトはBLOBにするか、シリアライズしてまるごと保存するので、保存するだけならこの仕組みは要らない。この仕組みは検索可能な属性を定義するときのため。

DBクラス

検索は必要。

アプリ側では全文検索をするのでフラットファイルを使う場合はすべてのキーをアプリ側で保持しなければならない。

必要な操作は「公開されているすべての投稿を新しい順に得る」といったこと。

レスポンスはデータを提供したサイト別にしなければならない。…というのはDBだけ公開したりしないので不要。

自サイトのデータのみ保存。モデル層から呼ぶDBのラッパークラスにする。

権限とWHERE句とORDER BY句を指定できればいい。オブジェクト全体はBLOB。型を示すMIMEタイプも。検索キーにしないデータはBLOB内にあるだけ。

SQLはモデル層のもの

DDLもバージョン番号をつけてモデル層に書く

ALTER TABLE 文もモデル層に書く

SQLを書かずにモデル層を豪華にしたい

改造しやすくするため

IDを持つオブジェクトは永続化される

IDを持たないオブジェクトは永続化されない

IDはオブジェクトの外から与えられる任意の文字列

データベースに同じIDが存在するなら上書き

更新されたオブジェクトだけを永続化

モデル層オブジェクトはFlyweightでなければならない

FlyweightFactoryが必要

モデル層クラス別のテーブル

クラス間継承を考慮せず、具体的なクラスごとに1つ