日付変わった辺りでこのサイトにアクセスしてみたら、ドメインが見つからんって怒られた。やっべ俺ドメイン更新忘れてたっけか？とふと思い返してみても確か更新は9月くらいにしたしまだ先のハズだよねと疑問に思っていたら繋がった。うん、まぁ単純にサーバが落ちてたんだろう。
研究だったりバイトだったり冬季鬱病発症かと悩んだり冬季鬱病っぽい友人の面倒みたり色々あるわけですが、ようやっとSQLを導入するための仕様がFixしそう？ 実際に作って様子を確かめてから完全にFixしようかとも思っているけど。まぁその辺りは流動的に変化するとして、Blog・Gallery・Libraryを統合するにあたってメインカテゴリを大幅増量することに。Archiveは再三Delの方向で決定しました。一部情報を抜粋して、今のメモあたりに書くかもしれないけども。
で、他人様のブログなども参考にカテゴリ分けを考えていたんですが、なんか細分化されたカテゴリと大まかなカテゴリを同一レベルで扱うのに抵抗がありまして。例えばこのサイトであれば、SSとかイラストとかいった大カテゴリのほかに、それに付随する「オリジナル」「イルカ」「PSO」「AIR」といった小カテゴリもあるんですよ。他のブログではこの辺りを同一視して分類しているようですけど、個人的にそれは気持ちが悪い。かといって小カテゴリを無視するようにしてしまうとそれはそれで利便性が損なわれてしまう。選択肢が減るわけですから、当然利便性が低下するわけで。
大きく分けると利便性が損なわれ、小さく分けると雑然としてしまい、と困ったんですけども。カテゴリを段階分けすることでこれを解決することにしました。つまり、大カテゴリを「メインカテゴリ」、小カテゴリを「サブカテゴリ」として、SQLのテーブルに加えるんです。メイン・サブと分けていても、基本的にSQLクエリ上の扱いでは同一。PHPがHTMLで吐き出す時には各層で整理して表示が出来るという中庸案ですよ。場当たり的とも言いますけど。
まぁ、3層型にするほど細分化しなくても大丈夫（メイン・サブの使い分けでだいたいカバーできる）みたいだし、もし必要になったらもう一つカテゴリテーブルを追加するようにデータベースを弄ればいいし。同一テーブルで、検索クエリの内容を階層分けする方法もあるんだろうけど、どっちのほうがスマートだろうか。結局メイン・サブでどこかにカテゴリ情報を保存しておくことになるから、テーブルを一つにするか二つにするかはあまり変わらない気がするけど。後々の拡張性を考慮すると、テーブルは一つで、カテゴリ情報について階層分けするようにしたほうがいいかもしんない。ブログのアルゴリズムにも依るか。
金曜日からはセンター試験のため、学部周辺がピリピリすること請け合いなので、不必要なトラブルを避けるために研究室には立ち寄らないことにします。入場許可証貰ってくるの忘れたしな。どうせ大半バイトだし。明後日辺りにまとめて仕様をプログラムに書き起こしてみよう。
Comment