小杉です


> 神崎です。
>
（中略）

> 10000.50000.40000
> だと
> xxxx1xxxx5xxxx4
> ということですか？
> これだとxxxx1xxxx5xxxx4のような桁数が255を超えた場合はやはり足
りなくなりますよね？
> しかも15686のような数値はどのように表しますか？
> もしかして私の認識間違ってます？
>
>


桁数としては、char(255)じゃなくて、textにするとかなり融通が利きま
す。それでも私は、順序キーはcharの方が向いていると考えていますの
で、フィールドの桁数がオーバーフローしたときのために、オーバーフ
ローした分を次のフィールドで吸収するように設計します。スレッド毎
に新しいnoが振られるのでmsgNoを順序キーに当てていくケースに比べ
て、巨大な数字が振られることはまずないのですが、私の推薦する記法
ですと、莫大な数字でも、問題はありません。


便宜的に、記法を理解しやすくするために１０進で示してみましたが、
もし１０=Xだけを使うと、

10000=xxxxxxxxxxxxxxxxxxxxxxxx..............snip..........xxxxxxx
x0
となります。
これでは、使い物になりません。
#ちなみに、１０進でxxxx1xxxx5xxxx4は、41.45.44です
この意味は、スレッドに対して４１個目のレスで、それに対するレスの
４５個目のレスにでさらにそれに対して４４個のレスがついた状態で
す。

しかし、この記法は、さらに応用することが出来て、３０進数＋桁添字
５字で同じことが出来ます。
0は特殊な意味がありますので１から始めて
1,2,3,4,5,6,7,8,9,a,b,c,d,e,f,g...........t
までを進数として
u=30
v=120
w=360
x=1080
y=3240
z=9720
の添字とします

すると、15686は
zyxxwvuuq
となります。１〜ｔとu〜ｚは意味が違うのでそこが切れ目になります。

では、
zzyyxwvu5xxwvucxxugyywwvvt
これも一意に１０進数とdotの並びに変換できます。
しかも、ソートに対しても矛盾はありません。
#これは、ひとつのスレッドに対して約20000のレスがつき、そのレスに
約2500のレスがつき、さらに、約2500レス、約10000レスがついたという
ケースでの順序キーです。

このように、記法的には無制限に対応できます。
これは、あくまでも例ですので、運用に合わせて進数と添字を調整する
べきですが。
進数をもっと増やして、添字の精度をあげると圧縮効果はかなり高いで
す。

ただ、この記法に頼るのではなく、階層が深くなった場合と、スレッド
内のメッセージ数が莫大になったときの対策はもっとスマートな方法が
必要です。この記法の最大のパフォーマンスは１０〜５００レスぐらい
とおもわれますので、それ以上を想定して例外処理を加えておく必要が
あるでしょう。

例えば、
ひとつのスレッド内でレスの数が莫大になるケース、階層がやたら深く
なるケース、またはその両方があると思いますが、自動的にtreeそのも
のをネストするなどの対策をとります。treeが分岐する元になるメッ
セージを検出してそこをネストの元とします。
（ネストフラグ用のフィールドを用意します）

人によってはこういう例外処理を嫌う方もいますが、このケースでは早
めに例外を発生させてそれを適切に処理する方法の方が向いていると感
じています。
なぜなら、無限に増え続ける可能性があるものに対して、有限の桁数で
対応しようとしているわけですから、例外処理で有限の問題を回避する
処理はどのみち必要です。こういうケースでは、単純なテーブルとロ
ジックで致命的な例外が生じるよりは、早めに例外を発生させて処理す
る仕組みを準備するほうが向いています。




--
Tomoaki Kosugi
kosugi@xxxxxxxxxx