3

私は Web 開発とローカル アプリケーションのために Apache、PHP、および MySQL を使用しています。ここ数年、私はゆっくりと C++ を学んでおり、今年の夏にアプリケーションを構築したいと考えています。具体的には、私が所有している本、CD、およびレコードに関する情報を保存できる「ライブラリ」アプリケーションを作成したいと考えています。このタイプのアプリが存在することは知っていますが、C++ を学びたいので、これが良い方法のように思えます。

ここにいくつかの質問があります：

  1. データを格納するためのデータベースを必要としないスタンドアロン アプリケーションを作成することは可能ですか?

  2. 上記の #1 に対する答えが「はい」の場合、大量のデータを管理する必要がある可能性のあるアプリケーションに対してこれを行うのは良い考えですか?

  3. C++ アプリケーションで使用する場合、どのデータ ストレージ オプションをお勧めしますか?

ありがとう！

更新 さて、これには多くの良い答えがありました。これは非常に多くの貢献者がいる素晴らしいサイトです。今のところ、C++ ルートに行く必要はあまりないかもしれません。私は、 C++ を追求するよりも、「ライブラリ」組織システムとして機能できるアプリケーションを作成することに最も関心があることに気付きました。みなさん、回答ありがとうございます！

4

6 に答える 6

6

データを格納するためのデータベースを必要としないスタンドアロン アプリケーションを作成することは可能ですか?

はい、データを保存するために何らかのカスタム ファイル形式を作成できます。

上記の #1 に対する答えが「はい」の場合、大量のデータを管理する必要がある可能性のあるアプリケーションに対してこれを行うのは良い考えですか?

構造化ファイルにデータを保存する方法を本当に知りたい場合を除き、これは良い考えではありません。

C++ アプリケーションで使用する場合、どのデータ ストレージ オプションをお勧めしますか?

私はSQLiteを見たいと思います。これはデータベースですが、別のエンジンは必要ありません。

于 2010-05-22T16:06:20.830 に答える
2

データベースを使用したくない場合は、データをファイル (または複数) に保存することをお勧めします。もしそうなら、問題はおそらく次のとおりです。どのファイル形式が最適ですか? 答えは、さまざまな要因によって異なります。

1) アクセスが速く、サイズが小さく、解析が容易か? 答えは「バイナリデータ」です。fwriteを使用して、データをそのまま出力ファイルに直接書き込むだけです。欠点が 2 つあります。ファイルは人間が判読できないことと、異なるバージョンを維持するのが面倒なことです。読み取ったデータが期待どおりでない場合、すぐに問題が発生します。

2) 人間が判読でき、保守が容易か? それが XML の目的です。データをファイルに書き込むための優れたツールである tinyXML のようなすぐに使用できるパーサーがあります。欠点は、ロード/保存ルーチンの作成に時間がかかることです (多くの場合が多い)。

3) あなたのために仕事をする図書館。MFC は CArchive クラスを提供しますが、これを行うための他の、おそらくより優れたツールがあります。

于 2010-05-22T16:08:08.750 に答える
1

うーん...

もちろん、あなたはこれを行うことができます。

あなたが話しているのは、RDBMSが成功する前の期間にタイムスリップすることです。これを行うのは難しいことではありませんが、学んだいくつかの教訓を学ぶこともできます。

  1. コーディングを開始する前に、または少なくともデータアクセスコードを作成する前に、データベースを使用する場合と同じようにデータベース設計を行います。どのようなデータが必要ですか。必要な属性（「フィールド」）の数を減らすことができますか？ライブラリ内のメディアタイプ間の共通点は何ですか？等
  2. アドホックなストレージ構造のビットとして、ディレクトリツリーとファイル名の使用を検討してください。これにより、プログラムの現在の能力を超えてデータを管理する必要がある場合、または管理したい場合に、データがコマンドラインユーティリティの手に直接渡されます。たとえば、本はすべて本のサブディレクトリにあり、その中でISBNまたはタイトルをファイル名として使用できます。ls、dir、またはCLIが使用するものを使用して、ファイル名として自然にソートされるものを探します。
  3. もう1つの良い選択は、XML形式で配置することです。おそらく両方-全体的なデータレイアウトにディレクトリ階層を使用し、ライブラリエントリデータをXML形式のフラットファイルに配置します。これは、ある時点で便利であることが判明する可能性があります。
  4. データはプレーンテキスト形式でのみ文字列として入力してください。バイナリデータは使用できません。これも、プログラムの外部のデータにアクセス/操作できるようにするために重要です。
  5. このような戦略では、必要に応じて、grep、sed、lexなどのシステムツールを使用して、データに対して完全に計画外の処理を実行できます。
  6. 「データベース」をウォークし、その内容全体をプレーンテキストとしてエントリごとに1行出力する機能を使用するか、別のリーダープログラムを作成します。出力するメディアの種類などを指定するオプションがある場合もあります。また、出力の属性間で使用される区切り文字を設定できるフラグを含めることもできます。カンマ区切りが一般的な選択ですが、スペースが必要な場合もあります。キャリッジリターン、改行、またはその他。これをオプションのフラグにして、ユーザーが何でも使用できるようにし、お気に入りのデフォルトを提供する場合は、問題ないはずです。
  7. コードをモジュール化して、プログラム全体を再ハッキングする必要がなく、後でストレージ戦略を置き換えることができるようにします。複数のストレージ戦略を提供することもできます。

これはそれをするべきです。

最新のコンピューターハードウェアで管理するデータの量がパフォーマンスやスペースの問題になる可能性は低いため、数バイトを節約することを心配する必要はありません。面倒なことをする価値はありません。

頑張って、乗り心地を楽しんでください。

于 2010-05-22T16:22:47.667 に答える
1
  1. はい。
  2. そうである可能性もありますが、ニーズが見た目よりも専門的でない限り、汎用データベース マネージャーを使用することをお勧めします。
  3. このようなものについては、利用可能な (多くの) 組み込み可能なデータベース マネージャーの 1 つを使用することを考えています。

(明らかに) 実際の使用ではなく主に独学でこれを行っていることを考えると、ストレージを処理するデータベース マネージャーなしでコードを記述することは理にかなっているかもしれません。自分ですべてのコードを (少し注意して) 書くと、かなりの余分な作業が必要になり、通常はある程度の柔軟性が失われますが、通常はわずかに高速になります。学習の観点から見た最大の問題は、これを行うことで学んだことのかなりの部分が、かなり狭い状況でしか適用できないことです (つまり、ほとんどの典型的なアプリケーションでは、データベース マネージャーを使用する必要があるため、データベース マネージャーなしで行うことを学ぶことはほとんど得られません)。 ）。

使用目的/対象者によっても少し異なります。一度に複数のユーザーをサポートしたい場合は、ほとんどすぐに (少なくとも効率的には) 事態はさらに困難になります。一度に 1 人のユーザーのみがデータベースにアクセスできることに関心がある場合は、そのほうがずっと簡単です。

于 2010-05-22T16:11:01.427 に答える
1
  1. はい
  2. データにもよりますが、「大量のデータ」は相対的なものです。1000 冊の本に関する情報は数 MB に格納できることがわかる場合があります。 sqlite
  3. CSVやXMLなどのプレーン テキスト形式に固執することをお勧めします。

学習のために、SQL とリレーショナル DB の設計を学びたい場合を除き、DB エンジンを使用しないことは非常に役立ちます。一方、DB エンジンを使用すると、さまざまなデータのインデックスを作成して簡単かつ効率的に検索できるため、開発がより迅速かつ簡単になります。

だからそれはあなた次第です。

于 2010-05-22T16:16:04.847 に答える
0

SQLiteもお勧めします。

彼らのウェブページから：

「SQLiteは、自己完結型のサーバーレス、ゼロ構成のトランザクションSQLデータベースエンジンを実装するソフトウェアライブラリです。SQLiteは、世界で最も広く展開されているSQLデータベースエンジンです。SQLiteのソースコードは、パブリックドメインにあります。」

「SQLiteをOracleの代わりとしてではなく、fopen（）の代わりとして考えてください。」

于 2010-05-22T17:02:08.973 に答える