[Namazu-devel-ja 1269] Re: ptknamazu

[Tadamasa Teranishi]

寺西です。

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 ＠ asahi-net.or.jp
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E