2006年9月26日

[Namazu-devel-ja 1269] Re: ptknamazu

寺西です。

NOKUBI Takatsugu wrote:
>
> あと複数のSQLエンジンをサポートしようとした時、SQL方言の吸収の問題が
> ありますが、それもO/R mapperがよく使われる理由のひとつだと思っています。

そうですね。複数の SQL エンジンをサポートしようとすると...です。

それと、

> > が、それは SQL に関しては Namazu の範囲外とした場合の話でして、
> > SQL の導入に関する説明だとかをしないといけなくなると、プロジェクト全体
> > として保守が減るかどうかは微妙かもしれません。
>
> 確かにbackendの選定によっては、敷居がずっと大きくなるかも知れません
> ね。

というのを合わせると、

> > のですが、そのために何らかの SQL プログラムをインストールするのは
> > さすがに敷居が高いですね。

という話になります。

> そういう意味ではSQLiteは確かに選択肢としてはいいのでしょうが、いか
> んせん知人の話を聞いていると、ちょっとどうなのかなという気がしています。

はい。手軽な SQL エンジンとして SQLite はどうだろうと安易に思ったの
ですが、実際使われている方の印象がそうならダメなんでしょう。

# それでも今よりはマシだろうけど。

> > こういったリカバリーツールって、どういう仕組みで直すんでしょう。
> > 直せるものと直せないものがあるとは思いますが、どの程度の破損なら
> > 修復できるものなのでしょう。
>
> トランザクションを持っていれば、そのチェックポイントに戻すことでとり
> あえずなんとかなるようです。

あぁ、そういうことですね。

BDB のリカバリーはチェックポイントに戻すってわけじゃないでしょうけど、
どうしているのだろう??

BDB を使うとしても、チェックポイントに戻すという機能を考えたインデックス
の設計は必要だなぁ。

> > > 加えて、QDBMのバージョンがあがるとABIやデータ形式がよく変わるので、
> > > BDBよりある意味厳しいように思います。
> >
> > あれ? 今は割と安定しているように見えましたが、よく変わりましたか。
>
> ちょっと前にQDBMのリカバーをサポートするためにデータ形式が変わったよ
> うに記憶しています。ちょっと記憶があいまいかもしれません。

最近でしたか。
--
=====================================================================
寺西 忠勝(TADAMASA TERANISHI) yw3t-trns@xxxxx
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E

_______________________________________________
Namazu-devel-ja mailing list
Namazu-devel-ja@xxxxx
http://www.namazu.org/cgi-bin/mailman/listinfo/namazu-devel-ja

投稿者 xml-rpc : 2006年9月26日 14:17
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/46603
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。