セッションデータの削除
セッションファイルの削除 - 永字八法の続き。
ヒロインリコメンダーでは、CGI::Session::PostgreSQLを使ってる。
(ちなみにCGI::Sessionやそのバリエーションは、全部PurePerlなので鯖にコピペして置くだけで使えるのがありがたい。CPANしなくてすむ。)
しかしそうするとこの自動的にセッションを削除してくれるルーチンが役立たずになるので、新たな方法を考えなければならない。
多分、PostgreSQLのTRIGGERで何とかなるんじゃないかな。
セッションのほかにセッションの最終保存時刻を保存するテーブルを作る。これを仮に、sessions_dateとでもしようか。
CREATE TABLE sessions_date ( id CHAR(32) NOT NULL, last_use TIMESTAMP NOT NULL DEFAULT now() );
こんな感じかな?
そして三つのトリガーを作る。
- INSERT用。セッションが増えたら、sessions_dateにレコードを追加する。
- UPDATE用。セッションが保存、sessions_dateのレコードを更新する。
- DELETE用。セッションが減ったら、sessions_dateのレコードを削除する。
こうしておいて、一日一回くらい、以下のSQLを実行する。
DELETE FROM sessions WHERE id IN (SELECT id FROM sessions_date WHERE last_use < now()-1);
こうすれば、最終更新から1日が経過したセッションが全部消える……と思うんだけどどうですか。
※諸事情により、Perlにてちょこちょこ実装。
セッションデータの削除
セッションファイルの削除 - 永字八法の続き。
ヒロインリコメンダーでは、CGI::Session::PostgreSQLを使ってる。
(ちなみにCGI::Sessionやそのバリエーションは、全部PurePerlなので鯖にコピペして置くだけで使えるのがありがたい。CPANしなくてすむ。)
しかしそうするとこの自動的にセッションを削除してくれるルーチンが役立たずになるので、新たな方法を考えなければならない。
多分、PostgreSQLのTRIGGERで何とかなるんじゃないかな。
セッションのほかにセッションの最終保存時刻を保存するテーブルを作る。これを仮に、sessions_dateとでもしようか。
CREATE TABLE sessions_date ( id CHAR(32) NOT NULL, last_use TIMESTAMP NOT NULL DEFAULT now() );
こんな感じかな?
そして三つのトリガーを作る。
- INSERT用。セッションが増えたら、sessions_dateにレコードを追加する。
- UPDATE用。セッションが保存、sessions_dateのレコードを更新する。
- DELETE用。セッションが減ったら、sessions_dateのレコードを削除する。
こうしておいて、一日一回くらい、以下のSQLを実行する。
DELETE FROM sessions WHERE id IN (SELECT id FROM sessions_date WHERE last_use < now()-1);
こうすれば、最終更新から1日が経過したセッションが全部消える……と思うんだけどどうですか。
※諸事情により、Perlにてちょこちょこ実装。
セッションデータの削除
セッションファイルの削除 - 永字八法の続き。
ヒロインリコメンダーでは、CGI::Session::PostgreSQLを使ってる。
(ちなみにCGI::Sessionやそのバリエーションは、全部PurePerlなので鯖にコピペして置くだけで使えるのがありがたい。CPANしなくてすむ。)
しかしそうするとこの自動的にセッションを削除してくれるルーチンが役立たずになるので、新たな方法を考えなければならない。
多分、PostgreSQLのTRIGGERで何とかなるんじゃないかな。
セッションのほかにセッションの最終保存時刻を保存するテーブルを作る。これを仮に、sessions_dateとでもしようか。
CREATE TABLE sessions_date ( id CHAR(32) NOT NULL, last_use TIMESTAMP NOT NULL DEFAULT now() );
こんな感じかな?
そして三つのトリガーを作る。
- INSERT用。セッションが増えたら、sessions_dateにレコードを追加する。
- UPDATE用。セッションが保存、sessions_dateのレコードを更新する。
- DELETE用。セッションが減ったら、sessions_dateのレコードを削除する。
こうしておいて、一日一回くらい、以下のSQLを実行する。
DELETE FROM sessions WHERE id IN (SELECT id FROM sessions_date WHERE last_use < now()-1);
こうすれば、最終更新から1日が経過したセッションが全部消える……と思うんだけどどうですか。
※諸事情により、Perlにてちょこちょこ実装。
wikiっぽい物の続き
テーブル構造
アイテムテーブル
item_id | item_name | item_text | item_entry | item_update |
---|---|---|---|---|
varchar型。アイテムのID。 | varchar型。アイテム名。 | text型。アイテムの説明。 | 日付型。このアイテムの投稿日時 | 日付型。このアイテムの最終変更日時 |
関係テーブル
item_id_a | item_id_b |
---|---|
関係のあるitem_id | 関係のあるitem_id |
wikiっぽい物の続き
テーブル構造
アイテムテーブル
item_id | item_name | item_text | item_entry | item_update |
---|---|---|---|---|
varchar型。アイテムのID。 | varchar型。アイテム名。 | text型。アイテムの説明。 | 日付型。このアイテムの投稿日時 | 日付型。このアイテムの最終変更日時 |
関係テーブル
item_id_a | item_id_b |
---|---|
関係のあるitem_id | 関係のあるitem_id |
wikiっぽい物の続き
テーブル構造
アイテムテーブル
item_id | item_name | item_text | item_entry | item_update |
---|---|---|---|---|
varchar型。アイテムのID。 | varchar型。アイテム名。 | text型。アイテムの説明。 | 日付型。このアイテムの投稿日時 | 日付型。このアイテムの最終変更日時 |
関係テーブル
item_id_a | item_id_b |
---|---|
関係のあるitem_id | 関係のあるitem_id |
wikiっぽい何か
wikiっぽい物を考えてみた。一つのジャンルの総合的な辞書を目的とするデータベースだ。
(以下、全面的に書き直し)
普通のwikiについて確認しよう。
普通のwikiでは、キーワードを作り、そこに説明文を追加する。その説明文の中に、既存のキーワードがあった場合、そこへのリンクが自動的に張られる。
この方式だと、こういう問題が生じる。
- キーワードリンクが一方通行である。
- キーワードAからキーワードBにはいけるが、キーワードBからキーワードAにいけるとは限らない。
- 新しいキーワードが追加された場合、それ以前の説明文は古いまま
- キーワードCが追加された場合、キーワードAの説明文の中にキーワードCがあったとしても、キーワードAからキーワードCへはいけない。(毎回キーワードリンクを作成する手段もあるが、負荷が多過ぎて現実的ではない)
そこで、両方を解決するために、キーワードの説明文にリンクを盛り込む方式をやめ、専用のキーワードとキーワードの関連付けデータを持つようにする。
何かの作品とその作者名をそれぞれキーワードとみなせば、この二つのキーワードには関連付けが施してあり(あるはず。あるようにする)、キーワード「作品名」とキーワード「著者名」の両方から相互にリンクが張られていることになる。
また、関連キーワードは説明文から独立しているため、説明文がなくてもキーワードが成り立つし、説明文を変えたとしてもキーワードの言及関係が壊れることはない。
こういうキーワード同士の関連付けを行った上で、たとえばある本を登録する。
すると、「書名」「作者」「出版社」「出版年月」「メディアタイプ」が自動的にキーワード登録され(すでにされているならば登録しない)、なおかつ、「書名」と「作者」、「書名」と「出版社」、「書名」と「出版年月」、「書名」と「メディアタイプ」が関連付けられる。
そういう仕組みのものである。
「書名」で検索すれば、その本の情報が得られる。
「作者」で検索すれば、その著者がどんな本を書いたかが全てわかる。
「出版社」で検索すれば、その出版社からどんな本が出ているかが全てわかる。
「出版年月」で検索すれば、その年、その月にどんな本が出ているかが全てわかる。
以下略。
ここからがさらにオリジナルだが、「コンテンツ」と言う概念を導入する。
「コンテンツ」とは、作品そのもののイデアである。
これは以前も述べた例だが、「涼宮ハルヒ」と言う「コンテンツ」があったとすると、それは今まで出ている全ての「涼宮ハルヒ」シリーズの小説、漫画、そしてもしかしたらアニメ?の「書名」と関連付けられる。それと、作者である「谷川流」のキーワードとも関連付けられるべきである。
こうすることで、キーワード「涼宮ハルヒ」を表示すると、作者と「涼宮ハルヒ」関連で出た全てのグッズが表示されることになる。
同様に「キャラクター」も導入できる。
「キャラクター」はだいたいにおいて「コンテンツ」と関連づけておくと、検索の対象として充分であろう。キャラクター「長門有希」はコンテンツ「涼宮ハルヒ」と関連づけておけば、だいたいにおいて意味は通じる。
最後に、このblog時代に対応するために、全てのキーワードにはトラックバックとコメントを受け付けられるようにしておけば大丈夫だ。
こういうシステムを、夢想してみた。