[mhc:00682] Re: TSU_SPEED のマージの前に

[Yoshinari NOMURA <nom@xxxxxxxxxxxxxxxxxxx>]

On Thu, 1 Jun 2000 15:24:33 +0900,
	TSUCHIYA Masatoshi <tsuchiya@xxxxxxxxxxxxxxxxxxxxxxx> said:

> nom> -2nd +- Tue -(schedule1 schedule2 schedule3)
> nom>      +- Wed -(schedule4 schedule1)
> 
> はい、この方式を理解した上で、それでも検索が高速になるから大丈夫だろう
> と思って、実装が楽な方を取りました。

もちろん、土屋さんが理解していることは承知しています。
分かりました。実装とのトレードオフを考えられて、
そうされたのなら、異論はないです。

> nom> 試しに .schedule を 26個 cat して
> nom> C-c. で一度データを作らせておいて、
> nom> C-c. を 1回やってみると、速度は逆転しました。
> 
> ということは、理論上は intersect/ に 18 * 26 = 468 個のスケジュールを
> 置くと逆転すると予想されますね。
> 
> これって、かなり十分な数だと思うんですけど。

そうですか? 世の中には、とんでもないことをする人がいるので。
オーダについて気にしておくことは決っして損ではないと思います。
それに、もし、複数人で利用することになったらどうでしょうか?

# 今回の問題とは少しずれますが、僕の目の前で、日々の TV 番組情報
# を MHC にがんがん突込んで、滅茶苦茶な項目数を管理している人を
# みて、世の中には色々な人がいるなぁと思いました。

とんでもない面白いこと考える人が出て来たら、そのとき考えましょう。

> nom> X-SC-Schedule: の導入によって intersect/ に入る率が増えそうで、
> nom> ちょっと心配です。
> 
> これは以前にも提案しましたが、
> 
>     2000/intersect
>     2000/04
>     2000/04
>     ...
>     2001/intersect
>     ...
>     intersect/
> 
> という切り分けで、ある程度対処できるのではないでしょうか。

はい。

> S式と X-SC-Schedule: のサポート後、先々 slot の切り方等を
> もう一度考えたり、

がその心です。

長々とすみません。おかげさまで、僕の中では、
ほとんどクリアになりました。
いつでも TSU_SPEED を幹にマージしても大丈夫です。

# defmacro 問題はしばらくごめん、ってことで。
--
nom