続・移動ルーチンを考える

概要

[id:tsugehara:20060608:1149769590]
で記述したが、持ち駒の移動ルーチンはそんな事をやってしまうと問題が発生することが判明。
全ての駒に、「持ち駒になる場合の駒ID」を作らなければいけなくなるのだ。
持ち駒にはそもそも不要なデータである上、「歩」や「香車」などが持ち駒になった時に突然「金」になるわけもないのだから、この辺はプログラムで管理すればいいんじゃないか、という気もする。

だが、今度はもう一つ問題が生じる。
「歩」は「と」にクラスチェンジするわけだが、「と」は持ち駒になると「歩」に変換される。この変換式はどうすればいいか、という問題だ。
最も単純なのは「と」を参照しているクラスを探して、最下層のクラスを見つける、というパターンが考えられるが、「と」を参照しているクラスが二つあったらどうしたらいいだろうか。
さて、理想的な解決策は導き出せるか。

あまり理想的ではないが解決策

結局のところある程度DBを汎用的にする以上、「持ち駒になった場合の駒」という情報が必要ということ。
でも持ち駒になった場合の駒という情報はあまりにも限定的で、かつ基本的なテーブルを肥大化させる原因にもなり作りたくないので、アプリケーションごとの拡張領域を作成して、将棋の場合はそこに基底駒の情報が入っているという形式にしよう。

T_MST_KOMA
PK	KOMA_ID
	KOMA_NAME
FK	CHANGE_KOMA_ID
	TAG

フィールド名は後日じっくり考えるので見逃しのほどを。
TAGは不定長のテキストフィールドにして、XMLデータでも入れたいやつはXMLデータでもいれればいいし、好きなように使ってという形式にする。将棋ではKOMA_IDへの参照が格納されているか、またはnullの予定で、「と」、「歩」であれば「歩」のKOMA_IDが格納されているだけ、という形式にする予定。
よって駒をとると、TAGに格納されている駒が持ち駒として戻ってくる形式とし、移動に関してはデータとしてではなくプログラム側で制御する形式をとる。
本当はどういった種別のデータがTAGに格納されているかなどを示す情報などもほしいのだが、あまりギチギチにやりすぎると規模が大きくなりすぎるので、この辺りにしておくべきだろう。

さて、プレゼン用資料を以上の形式に修正して、本日14時からの会議に備えるとするかな。