2

現在、埋め込み可能なデータベース (C++、Win32) を探していて、SQLite が非常に魅力的であることがわかりました。ただし、ファイル パスをファイル プロパティと共に SQL データベースに保存することに意味があるのか​​どうかさえ疑問に思っています。ファイルの数は、サーバー システム上で数百または数千から数百万または数十億に及ぶ可能性があります。これは、ディスクの内容を探索するソフトウェア用です (ただし、ファイル自体の内容ではありません)。

私が考えていたのは、完全なディレクトリ部分を格納するテーブルと、ファイルのプロパティ (名前を含む) を格納する別のテーブルです。後者には、「親」フォルダーへの後方参照が含まれます。

私が検討していることの 1 つは、ディレクトリ テーブルに各ディレクトリのフル パスを格納する必要があるかどうかです。これにより、次のような冗長な情報が格納されることになります。

ID | Name
0  | C:
1  | C:\Windows
2  | C:\Windows\System32
3  | C:\Windows\System32\config

それ以外の：

ID | Name     | Parent
0  | C:       | NULL
1  | Windows  | 0
2  | System32 | 1
3  | config   | 2

もちろん、ある種のプルーニングまたは参照カウントがない限り、ストレージ/メモリの節約について「貪欲」になり、各文字列（各パスコンポーネント）の単一のインスタンスを保存することはできません...

どちらが優れていると思いますか?その理由は? 2 番目の方法では、パフォーマンスが低下しませんか?

また、 FLOSSであり、同様のもの (プロパティと共に階層パス名を格納する) を実装しているプロジェクトはありますか?

私が考えているスキーマでは、ファイルC:\Windows\System32\config\SOFTWAREは次のように表されます。

ID | Name   | Folder | Size    | Attributes | ...
42 | SYSTEM | 3      | 1024000 | 0x00000301 | ...
4

1 に答える 1

4

SQLiteはこれを簡単に処理できるはずです。SQLiteの適切な使用法を参照してください。

私はあなたのテーブルの2番目の自己結合形式を好みます。SQLiteは、Parentフィールドに含まれているIDをID（インデックスが必要です）に戻す際に問題が発生するはずです。ただし、Nameフィールドにもインデックスが必要です。これにより、テーブルに新しいエントリを挿入するときに、既存のフォルダをすばやく検索できます。

于 2012-10-23T11:14:54.610 に答える