Un*xにもレジストリー導入

1 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 07:52

Unixのコンフィグもいいかげん乱雑な/etc/*の手編集を
止めたほうがいい。key&valueをDBに突っ込んで、レジストリー
を構成するのはどう?実際Cobaltはに多様なことをやっていて
DBから/etcへコンフィグファイルを生成している。

2 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 08:05

まぁたしかに、linux なんかはそうしたほうがいいんじゃないかな。笑

3 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 08:11

>>1
おぅ、いいじゃん。
やってくれ。

4 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 11:19

>>1
勝手にやってくれ。お前しか使わんだろうが。

5 ：かえって管理が面倒だ ：2001/06/24(日) 11:44

君だけやれば良い。　>>1
（手作業が一番楽だったりするんだよナ）

6 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 13:44

カーネルモードにツリー形式も扱えるまともな、トランザクション
データベースがあればいいんだよな。
ファイルシステムはそのデータベースをディスクドライブにじかに
マッピングする形にすると。で、ファイルinファイルを出来るように
すればファイルシステムの中に更にレジストリみたいなものを簡単に構築
出来るようになる。通常のファイルアクセスはディレクトリなどの
ファイルシステム部分へのアクセスはトランザクションにして、データへの
アクセスはダンプするタイプとトランザクションでのアクセスの二つを用意する。
レジストリみたいなファイルの場合は全部トランザクションでいつでも
ロールバックできるようにすれば設定も元に戻すことができる。
ちょい昔だとこんなの馬鹿な話だったけど今なら十分可能だと思うんだけどね。

7 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 14:27

>>6
レジストリとファイルシステムの本質的な違いって何？
レジストリにこだわらなくて別にファイルシステムでいいんじゃない？
トランザクションってジャーナルじゃだめ？
レジストリの必要性がわからない。コンフィグファイルの統一化というのなら意味がわかるが･･･。

8 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 14:35

registry=thin file system

9 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 14:36

>>7
databaseとfilesystemとの違いを求めてどうする？

本質は同じで、>>6は特性の違いを述べているのではないか？

10 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 14:38

javaにもregisterとregistryがあるけど、駄目環境認定？

11 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 15:27

レジストリは退化だと思う。
いざというときに設定ファイルをcatで読んだり、書いたりしたことある?
レジストリを入れるくらいならlibcレベルでがっちりした、穴のない
設定ファイルparser を導入して、書式を統一させたほうがよい。

12 ：7 ：2001/06/24(日) 15:30

>>9

あほ？ジャーナルファイルシステムって知ってる？

13 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 15:45

Darwinはレジストリっぽい物使ってなかったっけ?
# いや、BSD magazineのhack記事にそんな話が載っていたような

14 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 16:02

rm -f /etc/registry
でシステム破壊か。

15 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 16:05

現状が最高だと思っている人たちばかりなの？

16 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 16:18

>>15
現状から変わればなんでもいいと思ってるの?

17 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 16:22

ごたくはいいから、まずはモノを作って見せてくれ。

18 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 16:23

LISP 式はどう？

19 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 18:15

>>13
アプリケーションの設定ファイルが XML で書式統一されてるので、同じ
コマンドで一応一通り処理できる。Xt のリソースと概念的にはにたよーなもん
Darwin の部分の大半は従来の UNIX と同じ個別の設定ファイル。
あ、名前情報は NetInfo に入ってる。

20 ：6 ：2001/06/24(日) 18:20

ファイルinファイルじゃなくてファイルシステムinファイルね。

WinのCOMみたいなコンポーネントオブジェクトを実現しようと思ったらどうする？
テキストファイルで設定ファイル作ってコンポーネントオブジェクトの参照
する度に設定ファイル上からスキャンするの？なんかの設定情報を探すのにetcの下grepするの？
そんなの非効率的でしょ。設定情報は一箇所にまとまっててかつ検索が早いほうがいい。
トランザクションで変更が管理できるならなお良い。
いまのWinのレジストリでも検索は弱い。だから山本風水式でレジストリデータを
まとめると速くなったりする。
トランザクションで変更が管理できて、ツリーになってる物ってファイルシステムも同じ
ものを必要としてるんだよ。だったら双方をサポートできるような構造にして同じコードを
使ったほうがメモリは食わないし、信頼性もあげやすい。そういう意味でのファイルシステムinファイル。
レジストリみたいな設定情報、ファイルシステム、通常のDB、3つの要求が1つのコードで
満たせるんだからいいと思うんだけどねえ。
Oracleが作ったwebサーバーなんかいいとこ行ってるよな。Oracleがカーネルモードで動いてて
ファイルシステムは無くて、webサーバーが直接OracleのDBからデータを読み込むように
なってる。惜しむらくはOracleがOSメーカーじゃなかったからOSとして作ることが出来なかった
とこだな。

21 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 19:04

要はトラぶった際に人力で解析したり書き換えたりできればいいだけなんじゃないの？
confファイルの中があまりにも汚ければだめだし、Winみたいに一括管理でも人間が見て
わかりやすい作りになっていれば問題ないと思う。

22 ：13 ：2001/06/24(日) 19:50

>>21
レジストリはリビジョン管理したくてもできないのがネックだと思う。
いや、ちゃんと更新履歴取ったり昔のバージョンとdiff取ったりする
仕組みがあるならレジストリでもいいんだろうけどさ。

23 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 19:54

Windowsのregistryの、HKEY_CURRENT_USER, HKEY_LOCAL_MACHINEって仕組み、
/etc/mailcap, ~/.mailcapみたいなユーザによる上書き、
って仕様になってないことが多いのは痛いな。NTとか複数人で使うとね。

それから、GUIでやりたくてLinux使っている人は、linuxconf使いなよ。

24 ：13 ：2001/06/24(日) 19:57

あとあれだ。
Windowsの場合アプリとOSの垣根がほとんどなくて、OSの設定なんだけど
Software\Microsoftに入ってたり、その逆とかかなりぐちゃぐちゃで
バックアップ取りづらくてたまらんので、symlinkみたいな仕組みもないと
駄目かも。

とか考えると、やっぱりこれってfilesystemそのものよね。

25 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 20:25

・テキストなのであらゆる方法で書き換えが可能。印刷保存も簡単
・ファイル単位でバックアップできる。サイズが小さいからFDでも可
・その場にバックアップファイルを置いておける（探す手間が省ける）
・コメントを書き込める。コメントアウトですぐに復帰できる

これらの利点を覆すようなモノができるのならば、
専用ツールで一元管理するレジストリのようなものに
移行してもよいが。

26 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 20:35

* 速度面と一元管理の面からDB(レジストリ)化する
* テキストも残し、テキストが変更されたらDBに反映、DBが変更されたら
　テキストに反映

うーん、負荷かかりそうだし不整合出そうでやだな。

27 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 20:57

「富豪的」に考えれば、parsingのコストなんか無視したほうが
よくない? DB化というのは貧乏くさい考えかただ。
ファイルシステムとparsingのための資源ががっぽり使えると
仮定すれば DB にする必要はないと思う。

28 ：#!/usr/local/bin/名無しさん ：2001/06/24(日) 21:29

>>26
/procみたいな仮想的なファイルシステムにするのが良いと思う。
ただ、何よりも先に設定ファイルの記述方法と、設定ファイルの構文解析処理の
両方の統一化が図られないといけないが。

29 ：#!/usr/local/bin/名無しさん ：2001/06/24(日) 21:34

>>27
レジストリ化したときのメリットが少なければテキスト化した方がよいと思うが、
* 統一的な履歴管理
* バックアップ／リストア処理の単純化
* 書式統一（および付随事項として構文解釈処理の統一化）。
がもしも達成できるとしたらレジストリ化するのも悪い選択肢ではないと思うのだが。

30 ：#!/usr/local/bin/名無しさん ：2001/06/24(日) 21:37

# どーでもいいことなのだが、名称が「レジストリ」だとイメージ的に
# 「（悪い意味で）混沌とした設定保存空間」みたいな感触を受けるの
# で、別の名称のほうがいいかも(藁

31 ：名無しさん＠入りますディレクトリ ：2001/06/24(日) 21:40

レジストリを作っても世界中のソフトウェアの方がついてこないな

32 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 21:42

レジストリっていうと確かにイメージ悪いな…

33 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 22:04

>>30,>>32
それは単にWinのアレと同じ名前だからでしょ。
専用DBで一元管理つーのが本質なわけで

34 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 22:07

AS/400......

35 ：SS ：2001/06/24(日) 22:26

UNIXにレジストリだなんて、やめてくれよ
レジストリ使ってて、これは便利と考えたこと無いよ
第一、重要な情報を、レジストリで一元管理していたら
ハッカーの餌食だよ。

36 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 22:31

>>35
ハッカーさんの食指が動いたとして、何か問題が起きるのかね?

37 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 22:47

>>３５
今は/etcの下に（ほぼ）全部集められているわけで。
ﾊｶｰの仕事のやりやすさなら、レジストリと大差ないと思われ

38 ：名無しさん＠Ｅｍａｃｓ ：2001/06/24(日) 22:47

いくつものドメインを抱えるレンタルサーバ業者なら、たいてい
ある設定ファイルからコマンド一発で Web や DNS や MTA の
設定ファイルを作るようなツール（といっても Makefile が
ほとんどだろうな）を独自に持ってるよ。新規にドメインが
契約されたり解約されたりするたびに設定をひとつづつ手で
書き換えるのは効率が悪すぎるもん。

レジストリではないけど、異なるサービスの設定を一元管理するのも
頭の使い方しだいでどうにでもなるってこと。

39 ：名無しさん＠お腹いっぱい。 ：2001/06/24(日) 22:49

>>35
いやな理屈だなぁ。
攻め込まれるのがいやだから城内を迷路にしてたみたいじゃん。
そうじゃなくて、単純に増改築を繰り返してきたから
使いづらくなったんだろ？

40 ：名無しさん＠お腹いっぱい ：2001/06/24(日) 23:09

セキュリティ強化の目的で、各confファイルを暗号化して、レジストリにするって言うのは？

41 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 07:08

>>40
暗号化すると各デーモンを立ち上げる度にパスワードを入れる必要があるんでしょ？やだ、そんなの。パーミッションじゃだめ？

42 ：初心者くん ：2001/06/25(月) 12:48

素人の浅知恵でなんですけど、アプリやサーバの定義ファイルなんかは各自バラバラな
書き方をしてるから、いっそのこと、xmlにしてくれればいいなと思うのですが。
だめっすか？慣れないvi（失礼）でタイプミス起こして延々悩むよりは。。。

43 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 12:56

うん、そう思う。設定ファイルの書式統一せよ!
でもフリーのUNIXの世界ではM$のような独裁者がいないから
開発者に言うこときかせるのはむずかしいと思うよ。
技術的な問題よりはむしろそっちのほうが問題。
なにかの形式がものすごく広まって de facto スタンダードに
なればよいけど、今のところそういうアプリケーションてあるかな。

44 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 13:18

レジストリねえ…
このスレッドで賛成意見書いている人って、設定ファイルのバージョン管理
とかしたことないんだろうなあ。

vi を使うのに困難を覚えるような人は、Windows 2000 使ってた方が幸せな
気もする。

45 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 14:15

>>44
そうか？
RCS なり CVS なりとはぜんぜん関係なくて、設定ファイルの書式が
バラバラであるということに異を唱えてるのだが。
つーか、ほんとにレジストリ方式で一元管理するならば、
関係ないものにまでミスが波及しないよう、今よりもさらに
バージョン管理の重要性が増すと思う。

46 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 14:23

＞ RCS なり CVS なりとはぜんぜん関係なくて、設定ファイルの書式が
＞ バラバラであるということに異を唱えてるのだが。

設定ファイルの書式を統一すると、inetd.conf とか passwd ファイルの
ような設定は、当然現在よりも複雑な書式にならざるを得ない (その結果、
エディタによる編集は面倒になり間違いも増える) けど、それでいいの？

設定ファイルの書式を統一するメリットというのは、常に統合化された
管理ツールを介して編集する場合だろうけど、個人的に、そういうのは
全くいらないなあ。エディタで十分。

管理作業で難しいのは、設定ファイルの意味を理解することであって、
設定ファイルの文法に関しては困難を覚えたことはないから。
typo の類はエラーメッセージ見れば一瞬で直せるし。

＞ つーか、ほんとにレジストリ方式で一元管理するならば、
＞ 関係ないものにまでミスが波及しないよう、今よりもさらに
＞ バージョン管理の重要性が増すと思う。

Windows のレジストリのバージョン管理って、全然駄目なんですけどー。
というわけで、反証が一例あるよ。

47 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 15:44

>>46
>Windows のレジストリのバージョン管理って、全然駄目なんですけどー。
>というわけで、反証が一例あるよ。

それはレジストリの考え方がいけないのではなくて
ユーザーレベルの概念の無いWin95から上がってきたから。
Win2000では多少改善されている、Win9xカーネルが絶滅し、
ソフトの対応も増えれば解決する。

いずれにせよ、レジストリシステムが使えないと云う証明にはならない。

48 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 16:29

> それはレジストリの考え方がいけないのではなくて
> ユーザーレベルの概念の無いWin95から上がってきたから。
> Win2000では多少改善されている、

Windows 2000 のレジストリ・サービスには cvs log や cvs diff や branch
の機能もあるのかな？ あと、各エントリーにコメントをつける機能も欲しいな。

> Win9xカーネルが絶滅し、ソフトの対応も増えれば解決する。

やっぱりレジストリが欲しいような人は Windows 2000 を使うべきだよねえ。

僕は現状の UNIX の設定ファイルで満足してるので必要ないっす。
というか、inetd.conf や passwd の形式が無用に複雑になるなんて嫌。

49 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 16:44

> 僕は現状の UNIX の設定ファイルで満足してるので必要ないっす

んー、だけど各 OS 間で設定ファイルのパスが
ばらばらなものがあって、それくらいは統一してもらえると
ありがたいよ。レジストリとは関係なく。

50 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 16:48

>>48
設定のデータ構造によって適切な書式というのは異なるのだから、
エディタでも書き換えやすい書式を作って統一しようというのは
難しいだろな。

>>49
同意。書式はバラバラでもいいが (サンプル見りゃわかるしな)、
せめて場所くらいはどうにかしてほしい。

51 ：login:bin (!=47) ：2001/06/25(月) 16:49

>>48
> Windows 2000 のレジストリ・サービスには cvs log や cvs diff や branch
> の機能もあるのかな？ あと、各エントリーにコメントをつける機能も欲しいな。

前半はレジストリ（設定ファイルのデータベース化）の本論とは別の話だろう。

Windows 2000のレジストリだってcvsと同じ入出力をするようなアプリケーションを
作れば良いだけだし、コメントだったら "#Comment" みたいにダミーの名前を付けて
あげれば良いだろう。レジストリの本筋は「情報を如何に保存するか」であって、
コメントを付けられるかどうかはユーザの利用次第でなんとでもなるだろうに。

ちょっと前にLinux系のメーリングリストで議論してたファイルシステム内の
ファイルの配置の統一化と似たような議論だな。あっちは "Unix互換システム
上でプログラム本体の置き場がバラバラなのをなんとかしよーぜ" だったのが、
こちらは "設定ファイルの書き方がバラバラなのをなんとかしよーぜ" なのだ
と思う。

> 僕は現状の UNIX の設定ファイルで満足してるので必要ないっす。
> というか、inetd.conf や passwd の形式が無用に複雑になるなんて嫌

別に複雑化しろなんて言ってないぞ。ただ、従来の物との互換性を保つための
仕掛け（XMLで書いても仮想的に /etc/ 以下においてあるように見えるとか）
は必要だろうな、移行措置として。

52 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 16:58

書式統一はともかく、XMLにする利点を教えてくれ

53 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 17:00

> 書式統一はともかく、XMLにする利点を教えてくれ

1. はやってる
2. カッコよさげ

XML使う理由なんてみんなこんなもんだろ。

54 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 17:06

げいつに洗脳されたノカ

55 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 21:21

レジストリーはカスタマイズデータの塊。不変のものと、
常に変化するものとは個別に管理したい、当然のなりゆき
だと思う。レジストリー導入に関して反対はしない。現に
AIXはODMというレジストリーと同じ概念のものを提供して
いる。WindowsにしてもAIXにしてもその実装と利用方法が
中途半端に感じる。それは、ユーザーに対して簡単にアクセス
を許さない流儀とコメントのなさ、にあるとおもう！
Windowsはregedit®edt32をAIXはかつてodmeditを提供し
いた。両方とも結果的にはシステムクラッシュへの扉をユーザー
に開放しただけ。システムの完成には何時会えるの？会えないの？
有り得ないの？

56 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 22:44

レジストリファイルが壊れたらみんなパァてのがやだ。
バイナリなのがやだ。
レジストリ設定するソフト必須なのがやだ。

とあるレジストリツリーの下がぐちゃぐちゃになるのと/etc以下が
ぐちゃぐちゃになるのに大差はないと思う。

57 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 23:27

メジャーなソフトの設定ファイルなら、インストール直後、
ファイルの先頭や要所要所にコメントアウトの形で
サンプル行が乗っているよね。細かい解説つきで。

それを開いて、コピペして、説明にしたがって書き換えれば
大抵のソフトは動き出すんだよね。

58 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 23:36

バイナリファイルは死んだデータである。

59 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 23:50

>>58
同意。
一箇所に設定を集めるのは便利かもしれないが
バイナリにしてしまってはデメリットが大きすぎる

60 ：名無しさん＠お腹いっぱい。 ：2001/06/25(月) 23:59

AIXのODMはレジストリといって差し支えないと思うが。
それだけでシステムすべてを設定しているわけではないけど。

61 ：名無しさん＠お腹いっぱい。 ：2001/06/26(火) 00:29

>>53
皆が自分と同じだと思わないほうが良いぞ.
あえて問うが、何故行思考でなければならないのだ?

62 ：名無しさん＠お腹いっぱい。 ：2001/06/26(火) 01:52

>>12
著しくヴァカなので腹たった。

transacted file system, commit and rollback control, 他にもいろいろいおうか？

とりあえずヴァカ殲滅しないと話が元に戻らないとオモワレ

63 ：名無しさん＠お腹いっぱい。 ：2001/06/26(火) 01:54

とりあえず、このスレからヴァカ認定発言をイタイ発言スレに持っていこう

64 ：名無しさん＠お腹いっぱい。 ：2001/06/26(火) 02:22

認定馬鹿の晒し首陳列完了

65 ：名無しさん＠お腹いっぱい。 ：2001/06/26(火) 04:29

まずは>>63だね。

66 ：名無しさん＠お腹いっぱい。 ：2001/06/26(火) 06:23

linuxconf を発展させてはどうだろう。
テキストとツリーと両刀使いで。

で、そのシステムは GUI から設定も
コマンドライン起動で問い合わせ＆変更もできるようにすると良い。

というかコマンドラインで設定ファイルの問い合わせ＆変更が
できるシステムを GUI 側から呼んでツリー表示すればいい。

67 ：名無しさん＠お腹いっぱい。 ：2001/06/26(火) 08:15

/procって揮発性のあるファイルシステムだから、レジストリ用途には向いていないと思われ。

68 ：名無しさん＠お腹いっぱい。 ：2001/06/26(火) 08:33

XML 形式に一票.
ただ、形式など別にどうでもよくて、
それをパースして必要なデータを簡単に取り込めるライブラリを開発者に提供して、
簡単に設定できるようなツールを利用者に提供すれば、結構広まるのでは?

これで、書式の統一は図れるし、クラッシュしてもテキストだから問題ない。
広まってくれれば、さらに優れた設定ツールが出てくるだろうし。
どんな設定ファイルでも一つの設定ソフトで管理できるようになるよね。

ただ、この手のツールは、
最終的にSWATみたいに、ブラウザで制御するような形になりそう。

69 ：名無しさん＠Ｅｍａｃｓ ：2001/06/26(火) 09:09

>>68
> ただ、形式など別にどうでもよくて、
> それをパースして必要なデータを簡単に取り込めるライブラリを開発者に提供して、
> 簡単に設定できるようなツールを利用者に提供すれば、結構広まるのでは?

じゃ Tcl 使え。(藁

70 ：名無しさん＠お腹いっぱい。 ：2001/06/26(火) 11:17

>>62
なんか君の気持ちよくわかるよ。>>12は馬鹿だね。
file systemもぶっちゃけた話ただのDatabaseってことわかってないよな。
馬鹿に馬鹿って言われてむかつくのは厨房だってわかっててもむかつく時は
むかつくもんだ。

71 ：ping ：2001/06/26(火) 13:50

>>70
>file systemもぶちゃけた話ただのDatabaseってこと
ちょっとぶっちゃけ過ぎじゃないですか？
Databaseはデータの内容まで保証するけど、file system
の方は、ジャーナルファイルシステムだとしてもデータの
内容までは保証しない。

ここまで書いておきながら申し訳なりませんが、データを
保証するファイルシステムがあるのかな？レスくださいね。

72 ：名無しさん＠お腹いっぱい。 ：2001/06/26(火) 14:23

>>68
gconf がそれじゃないの?

73 ：login:bin ：2001/06/26(火) 14:43

>>67
別に/procと同じファイルシステムにしろとはどこにも書いてないだろ。

/procを例に出したのは、仮想的なファイルシステム（＝実際にファイルが
存在するわけではないが、特定の記憶域内の情報の形態を変えてマッピング
するもの）の一例としてだ。

>>71
いつ「データベース」がデータの内容を保証するシステムになったのだ？

トランザクションベースのデータベースシステムは内容を保証しようとする
機構は存在するが、トランザクションという考え方すら存在しないデータベ
ースシステムだっていくらでもあるだろうに。

74 ：名無しさん＠お腹いっぱい。 ：2001/06/26(火) 14:55

>>73
そうだね。正確にはトランザクションデータベースですな。
70の人ですか。私からの質問への返事もお願いします。

75 ：70 ：2001/06/26(火) 16:09

俺は実物はみたこと無いけど、そういうファイルシステムはあるらしい。
だが、トランザクションがあろうがなかろうがそんなものはdatebaseの
本質的な問題じゃあないだろ。ある一定のキー(file systemの場合はパス名と、
ファイルオフセットだ)からデータを参照・変更する構造は紛れもなくdetabaseだ。
file systemはネームスペースがツリー型、データベースはカラム・ロウ型に
通常なっているだけであって、ツリー型のデータベースはレジストリをはじめ
いろいろ存在するし、カラム・ロウ型のfile systemだって実現できる。
実際、前レスでも書いたがOracleのWebサーバーはOracleをfile system代わりに
使ってるだろ。
ジャーナリングファイルシステムのようにメタデータの一貫性を保つような
ファイルシステムは更にトランザクションデータベースと似てくる。
メタデータの変更をトランザクションの必要なデータの変更とみなし、
通常のファイルデータの変更はダンプとみなす。もしアプリがファイルデータの
変更もトランザクションとしたいならそれもサポートする。こんなファイル
システムがあればまんまトランザクションデータベースとしても使えるだろ。
NFSだってリモートデータベースとみなすことも出来るし、NFSの要求を受け取って
SQLへ変換してSQLデータベースをNFSサーバーとして使うようなプロキシサーバー
すら不可能な話ではない。

read.cgi ver5.26+ (01/10/21-)