カテゴリーとブログ
2008年8月2日
Nucleusでは複数ブログに対応しているが、当然のことながらJeansでも対応させる。一方で、Jeansでは多層のカテゴリー分けが出来るようにするつもりだ。
Nucleusの場合、サブカテゴリーのためのプラグインを導入しなくても、複数ブログを複数のカテゴリーと考えれば、通常のカテゴリーを一段だけのサブカテゴリーとして扱うことが可能である。このような考え方が出来ることから、複数のブログと複数のカテゴリの間には明確な区分は無いことになる。
ならば、ブログという概念を一切導入せずに、すべてカテゴリという概念だけで処理できるのではないかと考えてみた。ただし、ここでの議論はJeansの内部処理をどう行うかだけについてである。ユーザーにとっては、ブログ及びカテゴリという両方の概念が存在する。
まず、Nucleusの場合にどうなっているかを、おさらいしてみる。

非常に簡潔で、明快な構造をしている。1つのアイテムに1つのカテゴリが、1つのカテゴリに1つのブログが対応。例えば、あるブログに属するアイテムの一覧を取得するようなSQLクエリーも、この構造を考えるだけで簡単に書ける(WHERE i.catid=c.cnumber AND c.blogid=b.bnumber AND b.bnumber=XXX)。
次に、純粋にサブカテゴリだけをサポートしてみると、次のようになる。

構造は明確。ただし、あるブログに属するアイテムの一覧を取得するためには、どうしても効率の悪いSQLクエリーにならざるをえない。それは、アイテムの属するカテゴリの親カテゴリだけを調べるだけでは駄目で、そのカテゴリの親や、遠い先祖までさかのぼって調べないといけないからである。したがって、このような構造をサポートするためには、どうしてもツリー構造を保存するためのテーブルを一つ用意しないといけない。そのツリー用のテーブルがどのような構造になるかは未定であるが、これを用意すれば、あるブログに属するアイテムの一覧や、あるカテゴリーに属するアイテムの一覧など、同じアルゴリズムで取得できるようになるはずである。
一方、ブログの概念をなくして、カテゴリだけにすると次のようになる。

ただし、ユーザーインターフェースとしてのブログの概念をなくすことは出来ないので、一部のカテゴリではブログフラグを立てて、ブログオプションと対応付けする必要がある。図では、そのようなカテゴリの右側にブログを配置してある。先の議論で述べた、ツリー用のテーブルは、この構造でもそのまま当てはめることが出来る。加えて、あるブログに属するアイテムの一覧は、あるカテゴリに属するアイテム一覧とまったく同じことになるので、この辺りのコードは簡潔に出来そう。
このように考えると良いこと尽くめのように見えるが、おそらく実際にはそうでは無い。例えば、ブログにおけるデフォルトカテゴリをどう指定するかとかの問題がある。また、ブログフラグが立っているカテゴリーが一つも存在しないようなケースも考えうるが、そういった場合にどう対処するかなど、構造上のカオスを生み出しそうな匂いが、ぷんぷんする。
ブログという概念をなくしてしまうという考え方は、構造をシンプルにするというより、むしろ複雑にしてしまうようだ。Jeansでは、上の3つの図のうち、真ん中の図の概念を採用することになると思う。
Nucleusの場合、サブカテゴリーのためのプラグインを導入しなくても、複数ブログを複数のカテゴリーと考えれば、通常のカテゴリーを一段だけのサブカテゴリーとして扱うことが可能である。このような考え方が出来ることから、複数のブログと複数のカテゴリの間には明確な区分は無いことになる。
ならば、ブログという概念を一切導入せずに、すべてカテゴリという概念だけで処理できるのではないかと考えてみた。ただし、ここでの議論はJeansの内部処理をどう行うかだけについてである。ユーザーにとっては、ブログ及びカテゴリという両方の概念が存在する。
まず、Nucleusの場合にどうなっているかを、おさらいしてみる。

非常に簡潔で、明快な構造をしている。1つのアイテムに1つのカテゴリが、1つのカテゴリに1つのブログが対応。例えば、あるブログに属するアイテムの一覧を取得するようなSQLクエリーも、この構造を考えるだけで簡単に書ける(WHERE i.catid=c.cnumber AND c.blogid=b.bnumber AND b.bnumber=XXX)。
次に、純粋にサブカテゴリだけをサポートしてみると、次のようになる。

構造は明確。ただし、あるブログに属するアイテムの一覧を取得するためには、どうしても効率の悪いSQLクエリーにならざるをえない。それは、アイテムの属するカテゴリの親カテゴリだけを調べるだけでは駄目で、そのカテゴリの親や、遠い先祖までさかのぼって調べないといけないからである。したがって、このような構造をサポートするためには、どうしてもツリー構造を保存するためのテーブルを一つ用意しないといけない。そのツリー用のテーブルがどのような構造になるかは未定であるが、これを用意すれば、あるブログに属するアイテムの一覧や、あるカテゴリーに属するアイテムの一覧など、同じアルゴリズムで取得できるようになるはずである。
一方、ブログの概念をなくして、カテゴリだけにすると次のようになる。

ただし、ユーザーインターフェースとしてのブログの概念をなくすことは出来ないので、一部のカテゴリではブログフラグを立てて、ブログオプションと対応付けする必要がある。図では、そのようなカテゴリの右側にブログを配置してある。先の議論で述べた、ツリー用のテーブルは、この構造でもそのまま当てはめることが出来る。加えて、あるブログに属するアイテムの一覧は、あるカテゴリに属するアイテム一覧とまったく同じことになるので、この辺りのコードは簡潔に出来そう。
このように考えると良いこと尽くめのように見えるが、おそらく実際にはそうでは無い。例えば、ブログにおけるデフォルトカテゴリをどう指定するかとかの問題がある。また、ブログフラグが立っているカテゴリーが一つも存在しないようなケースも考えうるが、そういった場合にどう対処するかなど、構造上のカオスを生み出しそうな匂いが、ぷんぷんする。
ブログという概念をなくしてしまうという考え方は、構造をシンプルにするというより、むしろ複雑にしてしまうようだ。Jeansでは、上の3つの図のうち、真ん中の図の概念を採用することになると思う。