お知らせ『1月31日に一度初期化したいと思います。』　（他のお知らせを読むにはここをクリック）
並び順： 階層 時系列
0
+44		(・_・)テスト中につき反応鈍し◆JINX.xzK8k[1.29 20:34]
!m 複数行スレ☆
1
(・_・)bookbook[1.29 20:36]
おお！こんなことも出来るのか！☆
2
+42		(・_・)テスト中につき反応鈍し◆JINX.xzK8k[1.29 20:40]
☆
メッセージテーブルをmessage、ユーザーテーブルをuser、フォローテーブルをfollowとするとき

messageテーブルのカラム：id,body
userテーブルのカラムid
followテーブルのカラムfrom_id,to_id

SQL文：
select id,body
from message m,user u,follow f
where m.user_id = ログインID or u.id = f.from_id and m.user_id = f.to_id

例のため効率を無視した形なので若干速度的に難有り
3
+2		(・_・)テスト中につき反応鈍し◆JINX.xzK8k[1.29 20:41]>>2
☆
修正：
select m.id,m.body
from message m,user u,follow f
where m.user_id = ログインID or u.id = f.from_id and m.user_id = f.to_id
4
+1		(・_・)テスト中につき反応鈍し◆JINX.xzK8k[1.29 20:41]>>3
☆
また修正
select m.id,m.body
from message m,user u,follow f
where m.user_id = ログインID or ログインID = f.from_id and m.user_id = f.to_id
5
(・_・)テスト中につき反応鈍し◆JINX.xzK8k[1.29 20:43]>>4
☆
この例だとuser要らなかった・・・

select m.id,m.body
from message m,follow f
where m.user_id = ログインID or ログインID = f.from_id and m.user_id = f.to_id
6
(・_・)bookbook[1.29 20:46]>>2
☆
なるほどー。めっちゃシンプルに出来ちゃってる。
データベースって凄いな、まだまだ使いこなせてないや。
7
+37		(・_・)bookbook[1.29 20:51]>>2
あれ？フォローテーブルをユーザーごとに作ってるってこと？☆
8
+36		(・_・)テスト中につき反応鈍し◆JINX.xzK8k[1.29 20:54]>>7
☆
followのカラムはfrom_idとto_idで、from_idがフォローする側のユーザー、to_idがフォローされる側のユーザー
AさんとBさんが相互フォローしたら
1:from_id = A , to_id = B
2:from_id = B , to_id = A
こんな感じで二つのデータがテーブルに入る
9
+35		(・_・)bookbook[1.29 21:01]>>8
☆
なるほど、こうすれば一つのテーブルでフォローを管理できるのね。
ありがとう参考になる。
10
+33		(・_・)テスト中につき反応鈍し◆JINX.xzK8k[1.29 21:24]>>9
そういえば、結局ツリー構造には何の方式使うことにしたの？☆
12
+31		(・_・)bookbook[1.29 21:27]>>10
いまのとこ親のid持たせてるだけだよ。まだツリー表示までは作れてないけど。☆
14
+30		(・_・)テスト中につき反応鈍し◆JINX.xzK8k[1.29 21:32]>>12
☆
もし、テストじゃなくて実装のコードを書くとしたら、早めに環境の確認しておいたほうがいいよ
サーバによっては制約によって、使いたい命令が使えないなんてこともザラだから
たとえばtoyparkだとストアドプロシージャやロックなんかが使えなかった。他にも色々制限が・・・
自宅サーバならその辺はあまり問題ないけどね
15
+1		(・_・)bookbook[1.29 21:37]>>14
☆
全てが初めてだから、実装含めてテストコードみたいな感じだな。
ひと通り作れたら、環境とかそのへんのことも考えだすよ。
18
(T-T)テスト中につき反応鈍し◆JINX.xzK8k[1.29 21:42]>>15
ごめん。自分が苦労した経験から、ついつい先走ったこと書いちゃった☆
16
+27		(・_・)しらちゃ[1.29 21:37]>>14
ちなみに，ここでも私も発言しておくと，もし，あるゼロに対して，ツリー全体で，最大でn件(nは有限の値)のレスしか付けられないという制約を掛けるなら，私なら入れ子集合モデルというツリー表現形式を使います．☆
17
(・_・)しらちゃ[1.29 21:42]>>16
この方式なら，基本的にSQL文だけで実現できるうえ，考え方も簡単なので，多分この手のウェブサービスには向いてるはず．☆
19
+23		(・_・)テスト中につき反応鈍し◆JINX.xzK8k[1.29 21:43]>>16
Linenで使ってるの多分それだと思う。☆
21
+10		(・_・)しらちゃ[1.29 21:49]>>19
☆
ですよねえ．空間区切るための自然数2つのオーバヘッドなので，とても綺麗．
ゼロ発言をするたびに，最後に使った番号と，その番号にnの二乗を足した数がエンドインデックスになるので，発言のインデクスが巨大になりそうなのは，残念なところですが．
22
+9		(・_・)しらちゃ[1.29 21:51]>>21
Linenは100発言が限界？だから100**2 = 10000か．indexが32bitの自然数なら，だいたい429496回のゼロ発言を許容できる．Twitter程流行ると不味いかもしれないけど，十分だね．☆
23
+7		(・_・)テスト中につき反応鈍し◆JINX.xzK8k[1.29 21:59]>>22
あ、ゼロの左、右は1,2から始まる☆
24
+6		(・_・)しらちゃ[1.29 22:00]>>23
入れ子区間モデルのほうを使ってるんですね．そっちのほうが美しいですよね．☆
25
+5		(・_・)テスト中につき反応鈍し◆JINX.xzK8k[1.29 22:02]>>24
ただ、DBの方で付けるインデックスについては勉強不足であまり考慮してないから、これからもっと本読んで鍛える(｀・ω・´)☆
26
+4		(^-^)しらちゃ[1.29 22:06]>>25
お疲れ様ですー．ファイトです！数学とか理論の分野で，協力できることがあれば，お手伝いします～．☆
27
+1		(・_・)テスト中につき反応鈍し◆JINX.xzK8k[1.29 22:10]>>26
画面越しじゃ上手く質問できそうにないｗ会ってじっくり話してみたい気分ｗｗ☆
29
(^-^)しらちゃ[1.29 22:12]>>27
わーい，デートですね！デート．(違)☆
28
+1		(・_・)テスト中につき反応鈍し◆JINX.xzK8k[1.29 22:11]>>26
とりあえず、色々気になることがあったら聞きます！☆
30
(・_・)しらちゃ[1.29 22:18]>>28
了解ですー．☆
44
(・_・)wilodp[11:00]>>22
んー、n^2の猶予だと、ゼロの直下にレス付け続けられない・・・？☆
32
+11		(・_・)しらちゃ[1.29 23:23]>>19
n**2で足りる根拠を http://shiracha.net/~shiracha/linen/nestedsetmodel_maxsize.png に書いてみた．図だけだけど．結局，今回を配置した後，あり得る物を考えると，区分を2分の1にしていけば，最終的にn回の書き込みで切っちゃうから，絶対足りるってこと．☆
33
+10		(・_・)wilodp[1.29 23:34]>>32
☆
なるほど・・・
優位性は何と比較してるんでしょうか
34
(・_・)しらちゃ[1.29 23:35]>>33
入れ子集合モデル＋n発言制限と，入れ子区間モデルの比較です．入れ子集合モデルは，自然数を使った素朴な実装になるので，定数オーダではありますが，DB検索の高速性を保持できるという形ですね．☆
35
(・_・)しらちゃ[1.29 23:37]>>33
あと，暗黙の仮定として，ツリーの同じリーフは，末尾のリーフに追記されるという物があります．二つのリーフがあるときに，間に割り込みが入らないという仮定ですね．これはLinenの，現在の振る舞いの観察に基づいていますが，一般にルートから数えてn個のリーフしかない，という制限では，この根拠は崩れてしまいます．☆
36
+7		(・_・)しらちゃ[1.29 23:39]>>33
実装にトリッキーな部分がなくなるので，入れ子区間モデルのほうが美しい．けれども，定数オーダの速度まで気にするなら入れ子集合モデルのほうがよい……てことで，「私がLinenを実装するなら，入れ子集合モデルを使う」っていう発言と，「入れ子区間モデルを使ってるのですね，そっちのほうが美しいですよね」という発言に繋がってくるわけでした．ちゃんちゃん．☆
37
+6		(・_・)wilodp[1.29 23:57]>>36
☆
ふむ・・・
入れ子集合モデルが入れ子区間モデルを一般化した物で
入れ子集合モデルの考え方にｎ回発言制限を付けることで、
実装もシンプルに出来て、ＤＢの更新も高速だ
という理解になりました
38
+5		(・_・)しらちゃ[06:35]>>37
☆
いいえー．入れ子区間モデルのほうが，入れ子集合モデルの一般化ですー．
そして，一般には，入れ子区間モデルのほうが美しい実装になりがちです．
でも，n回発言制限があると，入れ子集合モデルのほうが軽い場合があります．と，いうことです．
39
+4		(・_・)wilodp[08:51]>>38
☆
なるほど。入れ子区間モデルのほうが一般化されている・・・脳内修正しました

n回発言制限を加えた実装だと、それが入れ子区間モデルなのか入れ子集合モデルなのかよくわからなくなってきた
定義の問題かな・・・・とりあえず仕事してから考えよう
40
+3		(・_・)しらちゃ[08:53]>>39
なんというか，私もこの辺の定義は，曖昧に理解しています．自然数で区間をインデクスするのが入れ子集合モデル，有理数・実数などの，稠密性を持った数でインデクスするのが入れ子区間モデルと想います．そしてn回制限は，自然数でもノード破壊が起きないことを保証するためのものなので，根本的に入れ子集合モデルのほうにしか必要がないものです．ただ，計算機は自然数のほうが，実数や有理数よりも得意なので，その点で高速性が保てるというのが利点です．(これは，非常に小さな利点でしかないので，おそらく入れ子区間モデルのほうが，「美しい」です)☆
41
+1		(・_・)しらちゃ[08:56]>>40
それでなぜ入れ子区間モデルのほうが，「一般化」というかといえば，歴史的に，入れ子集合モデルのほうが先に提起されていて，そこでは自然数を用いていたのに対して，「別にインデクスは何でもいいよね」と提起されたのが入れ子区間モデルだからです．何でもいいから，稠密性のある数を使うコトもできる．という感じですね．☆
42
(・_・)しらちゃ[08:59]>>41
さらに一般化したら，おそらくアベール群を何でも使うコトができそうです．が，まあその辺は考えても仕方のないことでしょう．☆
43
(・_・)wilodp[09:02]>>40
☆
なるほど・・・自然数だけで表したら入れ子集合モデル。そっちの解釈のほうがすっきりしますね

私は、入れ子区間モデルを使うというイメージが先にあって、それをn回発言制限のもとシステム内部的に自然数だけを使ったという方向で考えていました。
20
+1		(・_・)テスト中につき反応鈍し◆JINX.xzK8k[1.29 21:45]>>16
こんな名前知らなかった・・・☆
31
(・_・)wilodp[1.29 22:23]>>20
概念的なツリー名とアルゴリズムで呼び名が違うから☆
13
(・_・)bookbook[1.29 21:28]>>10
あ、親のメッセージのidね。☆
11
(・_・)テスト中につき反応鈍し◆JINX.xzK8k[1.29 21:25]>>9
あ、ツリーとは限らないのか☆