PostgreSQLのテーブル継承機能

位置情報サイト&技術者なのに位置情報DBを使わない(使えない)のはいかがなものか、というのがあるので、ケータイ版DBあぼーんしたのをきっかけにPostGISの勉強を決めた。
というか、まだその前段階のPostgreSQLの勉強中。

その先鋭的な機能の多さにびっくり。
まあそれぞれ良い点悪い点はあるが、しかし機能の先進さ、という点から見たらMySQLがおもちゃに思える。
なかでも驚いたのがテーブル継承機能。
いろいろテストしてみて、機能自体は制約が多いため使えない(少なくともノウハウもなく、全て独学でメンターもいない私には)事が判ったものの、そういうのをDB側で実装しようと言う姿勢に脱帽です。
というか、本当に欲しいし、オブジェクト指向とか言ったってデータを永続化しようと思えば、RDBに写像するしか現実的な選択肢がない中で、他のDBでなんでこういう発想が出てこないかが不思議ではあるけど。

というか、本当に欲しいんだよね。こういう機能。
例えば、ここギコでは、内部データは全て基底クラスを継承していて(実装と言うより、データ構造上でだけど)、ユーザであれモスバーガ店舗であれアンテナであれ、というかアンテナの個々の奪取履歴や掲示板の発言に至るまで、DB内で一意に指示できるユニークIDを持っている。
だから、実装が追いついているか否かは別として、原理的には、マイフォルダの中にお気に入りの場所も掲示板スレッドも友達ユーザも一緒に登録できるし、位置データを持っているオブジェクトならば、それが話題の場所であろうと過去の訪問履歴であろうと友達の現在地だろうと、まとめて近隣検索できる。
そういう構造をうまくRDBを使ったシステムで表現したいと思うんだけど、そうするとどうしても普通のDBでは細かくテーブルを分けて、複雑なSQL記述とプログラム側の処理とで対応してやるしかない(少なくとも私の頭では…)。

Class::DBI的なアプローチができれば劇的な工数削減ができてとても理想なんだけど、現状のClass::DBIでは1オブジェクト=1テーブルなので、複数テーブルが連合して(=継承して)1オブジェクトになるような構造は扱えない。
というか、Class::DBIを拡張して複数テーブル間のリレーションを内部管理して、1テーブルからなるClass::DBI継承クラスを継承して、2テーブルからなるクラスを作成→さらに継承…なんて事ができる構成を考えようと何度もしたんだけど、その度に挫折。
でも、PostgreSQLのように発想を変えてDB側でテーブル構造の継承をサポートしてくれれば、どれだけ構造を継承してもテーブルは1つなので、Class::DBIをそのまま適用出来ちゃうな、という夢のような事が実現するわけです。

まあ試してみると、現状は実装に問題が多すぎるみたいで使えなさそう。
例えば、親テーブルでのUNIQUE制約、いや主キー制約ですら、子テーブルには影響しない。
それどころか、制約のない子テーブルを通過したデータは、親テーブルに設定されているはずの制約の壁を越えて、親テーブルにまで挿入されてしまう。
つまり、親テーブルで主キー設定しているIDフィールドでも、子テーブルの方でユニーク設定されていなければ、同じID番号でいくらでも子テーブルに登録できてしまい、さらに恐ろしい事に、子テーブル登録を通過したデータは親テーブルにも無条件で追加されてしまうので、主キー設定しているにも関わらず値が重複、という事がありうるのだ。
まだ親・子が1対1関係なら子の方にもユニーク制約つければ何とかなるのだが、親テーブルがいくつもの子テーブルに継承されており、しかも子テーブル同士が必ずしも独立関係でない場合等に、問題が生じる。
また、継承関係が1世代の場合は、親テーブルで列を削除しても子テーブルで列を削除しても互いに反映されるみたいなんだけど、数世代に渡る場合、なんか妙なロックがかかってしまうみたいで、もっとも若い子孫になるテーブルでデータを削除しない限り、祖先テーブルでデータを削除してもデータが消えない(であるにも関わらず、例外も発生しない)。

というふうなあたりで、まだまだ使えるには問題がありそうだが(@7.4.3)、それでもPostgreSQLにしかないというこの野心的な機能に、今後も注目したいなと思います。

Posted with ecto