影舞のテーブル構成とか処理内容を調べてみました。postgresqlのところだけを、ななめ読み。全体のソースの印象は、すごく真面目に抽象化されていて、しっかりしたソースだと感じました。テーブルは、reports, messages, attachements という3つだけでした。各項目のカスタマイズ情報は、reporttype.xmlというファイルに格納されているようでした。reportsテーブルは、バグ1個につき1レコードに対応しています。messagesテーブルは、投稿、返信に対応しているようです。attachmentsテーブルは、添付ファイルです。ちょっと眺めただけですが、パフォーマンス対策で参考になる部分は、下のような感じでした。

• reportsテーブルに初回投稿のメッセージIDと最新のメッセージIDを格納するフィールドがある。
  • Starbug1では、この構成になってないがために、最初の投稿とか最新の投稿を特定するために、サブクエリで、maxとか、countとかしてたのがダメなところでした。
• カスタマイズによる項目の増減方法。
  • 影舞の方法は、正に、id:rayfillさんに教えていただいた方法でした。カラム追加、カラム削除を動的に発行するようです。

どう活かすか

で、Starbug1には、どう活かすかですが、今のところ考えていることをメモします。

• 今は、ticketテーブルとreplyテーブルで、投稿と返信を別扱いしているが、影舞と同じように、投稿と返信をmessageテーブルで同列に扱うようにする。
• ticketテーブルには、最初の投稿と、最新の投稿のmessage_idを持たせる。
• elementテーブルを廃止する。投稿された値は、messageテーブルに格納する。field_1, field_2というようなカラム名でいいかな？
• 管理ツールで項目を追加した場合は、messageテーブルにカラム追加するようにする。

なんか、参考というかコピーに近いかもしれない。

懸案事項というか自分の宿題

• 影舞は、項目のメタ情報は、reporttype.xmlに書いてある。しかし、Starbug1は、項目のメタ情報もDB(element_typeテーブル)に格納されているので、そこら辺を有利に使うこともできるかもしれない。
  • ストアドプロシージャとかトリガを多用するとか。

今度は、Sqliteのマニュアル(ストアドプロシージャ、トリガあたり)を見なくては。

追記：sqlite3にストアドプロシージャは無いようでした。