回答:
ファイルシステム内のプレーンテキストファイル
ディスク上のXMLまたはJSONファイル
スプレッドシート/ CSVファイル
Subversion（または同様のディスクベースのバージョン管理システム）
Berkeley DB（基本的に、ディスクベースのハッシュテーブル）
母国語コレクション（メモリに保存されているか、ディスクにシリアル化されている）
カスタム（手書き）ストレージエンジン
私はそれらについて多くを知っていると主張することはできませんが、オブジェクトデータベースシステムを調べることもできます。
Matt Sheppardの答えは素晴らしい（mod up）ですが、スピンドルについて考えるとき、これらの要素を考慮に入れます。
RDBMSに対するCSVファイルの特別な利点の1つは、簡単に圧縮して、他のほとんどのマシンに移動できることです。私たちは大規模なデータ転送を行い、すべてが1つの大きなCSVファイルを使用するだけで十分簡単で、rsyncなどのツールを使用して簡単にスクリプトを作成できます。大きなCSVファイルの繰り返しを減らすには、YAMLのようなものを使用できます。重要な関係要件がない限り、JSONやXMLなどを保存するかどうかはわかりません。
言及されていない代替案については、MapReduceのオープンソース実装であるHadoopを軽視しないでください。これは、分析する必要がある緩やかに構造化されたデータのTONがあり、データ処理を処理するために10台のマシンを追加するだけのシナリオにしたい場合にうまく機能します。
たとえば、私は約20台のマシンにわたって記録されたさまざまな機能の本質的にすべてのタイミング数であるパフォーマンスの分析を試み始めました。RDBMSにすべてを貼り付けようとしたところ、データを集約した後は、データを再度クエリする必要がないことに気付きました。そして、それは私にとってその集約されたフォーマットでのみ有用です。そのため、ログファイルを保持し、圧縮して、集計データをDBに残しています。
「大きな」サイズで考えることに慣れていることに注意してください。
ACIDが必要ない場合は、RDBMSのオーバーヘッドはおそらく必要ありません。したがって、最初にそれが必要かどうかを判断します。ここで提供されているRDBMS以外の回答のほとんどは、ACIDを提供していません。
カスタム（手書き）ストレージエンジン/必要なユースケースで潜在的に非常に高いパフォーマンス
膨大なデータセットがある場合は、独自のデータセットをローリングする代わりに、階層データフォーマットであるHDFを使用することができます。
http://en.wikipedia.org/wiki/Hierarchical_Data_Format：
HDFは、多次元配列、ラスターイメージ、テーブルなど、いくつかの異なるデータモデルをサポートしています。
また、ファイルシステムのように階層的ですが、データは1つの魔法のバイナリファイルに格納されます。
HDF5は、非常に大規模で複雑なデータコレクションの管理を可能にするスイートです。
ペタバイト級のNASA / JPLリモートセンシングデータを考えてみてください。
G'day、
モデル化しているデータをリレーショナルデータベースで簡単に表現できない場合が1つ考えられます。
そのような例の1つは、携帯電話事業者が携帯電話ネットワークの基地局を監視および制御するために使用するデータベースです。
私はこれらのケースのほとんどすべて、 、オブジェクトの階層を可能にする市販の製品または自己ロールシステムのいずれか OO DBを使用しています。
私は無名のままでいる大企業の3G監視アプリケーションに取り組んでいますが、そのロゴは赤ワインの染み（-：であり、そのようなOO DBを使用して、通信網。
このようなDBの問い合わせは、通常、SQLを完全に使用しない独自の手法を使用して行われます。
HTH。
乾杯、
ロブ
オブジェクトデータベースはリレーショナルデータベースではありません。データベースにいくつかのオブジェクトを詰め込みたいだけの場合は、とても便利です。また、データベースにすでに存在するオブジェクトのバージョン管理と変更クラスもサポートします。最初に思い浮かぶのはdb4oです。
OODBMSが組み込まれた、数年前に作成されたJADEというRADツールがありました。DBエンジンの初期の化身もDigitalk Smalltalkをサポートしていました。RDBMS以外のパラダイムを使用してアプリケーションのビルドをサンプリングする場合は、これが出発点になる場合があります。
他のOODBMS製品にはObjectivity、GemStoneが含まれます（Smalltalkバージョンを実行するにはVisualWorks Smalltalkを入手する必要がありますが、Javaバージョンもあります）。このスペースにはいくつかのオープンソースの研究プロジェクトもありました-EXODUSとその子孫が思い浮かぶはずです。
悲しいことに、おそらくSQLベースのRDMBSシステムと比較して、はっきりと見える標準がなく、アドホッククエリ機能が比較的貧弱であるため、この概念は死に絶えたように見えました。
OODBMSは、相互接続されたノードのグラフとして最もよく表されるコアデータ構造を持つアプリケーションに最適です。私は、典型的なOODBMSアプリケーションはマルチユーザーダンジョン（MUD）であり、部屋にはプレイヤーのアバターやその他のオブジェクトが含まれると言っていました。
ファイルシステムに保存されているファイルを使用するだけで、大きな成果が得られます。RDBMSはBlobの処理に優れていますが、これは特にクエリが単純な場合（個々のアイテムを列挙して選択する場合）、画像データなどを処理する自然な方法です。
RDBMSにうまく適合しない他の事柄は、階層データ構造であり、地理空間データと3Dモデルはどちらも扱いが難しいと思います。
Amazon S3のようなサービスは、SQLをサポートしないシンプルなストレージモデル（キー->値）を提供します。スケーラビリティが鍵となります。
特に、ユーザーが使い慣れた環境でデータを操作し、それを行うための完全なアプリケーションを構築する必要がある場合は、Excelファイルも役立ちます。
データを格納する方法は多数あります。「リレーショナルデータベース」でさえ、ローカルファイルを単一のユーザーベースのリレーショナルデータベースであるかのように操作するコードの単純なライブラリから、複数のユーザーを処理できるファイルベースのシステムよりも、深刻な「サーバー」ベースのシステムを豊富に選択できます。
私たちはXMLファイルを頻繁に使用します。適切に構造化されたデータ、同じようにクエリを実行するための優れたツール、必要に応じて編集を行う機能、人間が読める形式のものを使用するため、dbエンジンの動作（またはdbエンジン）。これは、本質的に読み取り専用のもの（この場合、他の場所のデータベースから生成されないことが多い）や、必要に応じてデータをロードして保存できるシングルユーザーシステムでもうまく機能しますが、機会を創出していますマルチユーザー編集が必要な場合の問題-少なくとも1つのファイルについて。
私たちにとってはそれだけです-SQLを実行するものを使用します（MSは.DLLから実行される一連のツールを提供して、エンタープライズサーバーに至るまでシングルユーザーを実行し、それらはすべて同じSQLを話します（下限に制限があります））または、（私たちにとって）冗長性がめったに問題にならないため、XMLをフォーマットとして使用します。
現在、アプリでバイナリデータを操作する必要はないので、問題は発生しません。
マーフ
多くの場合、BTreeファイルはリレーショナルデータベースよりもはるかに高速です。SQLiteには、パブリックドメインにあるBTreeライブラリが含まれています（本当は「パブリックドメイン」のように、用語を大まかに使用していません）。
率直に言って、もし私がマルチユーザーシステムが欲しかったなら、まともなサーバーリレーショナルデータベースを使わないようにたくさんの説得が必要になるでしょう。
「10ワード以内」などの近接演算子を使用して照会できるフルテキストデータベース
リレーショナルデータベースは、多くの目的に理想的なビジネスツールです。「フルパワーを使用する」ことができる天才によって設計および最適化されていない場合でも、理解と設計が十分に簡単で、十分に速く、適切です。
ただし、一部のビジネス目的では、全文索引付けが必要です。これは、リレーショナルエンジンでは提供されないか、後付けとして追加されません。特に、法務および医療分野には、構造化されていないテキストが大量に保存されており、それらを通過できます。
CAPの定理はそれを簡潔に説明しています。SQLは主に「強い整合性：更新が存在していても、すべてのクライアントが同じビューを見る」ことを提供します。
KISS：小さくシンプルに
私はRDBMSを提供します:)セットアップ/管理に問題がないと思わない場合は、SQLiteを使用してください。SQLを完全にサポートする組み込みRDBMS。また、任意のタイプのデータを任意の列に格納することもできます。
たとえばログファイルの例に対する主な利点：巨大なファイルがある場合、どのように検索するのですか？SQLエンジンを使用すると、インデックスを作成して操作を劇的に高速化できます。
全文検索について：SQLiteには全文検索用のモジュールもあります。
あなたのデータへの素敵な標準インターフェースを楽しんでください:)
リレーショナルデータベースを使用しない理由の1つは、大規模なデータセットがあり、そのデータに対して大規模な並列分散処理を実行したい場合です。グーグルのウェブインデックスはそのようなケースの完璧な例でしょう。
Hadoopには、Hadoop分散ファイルシステムと呼ばれるGoogleファイルシステムの実装もあります。
SQLiteの種類のデータストレージの代替としてLuaを強くお勧めします。
なぜなら：
これは、受け入れられた回答の「母国語コレクション」オプションです。アプリケーションレベルとしてC / C ++を使用している場合は、構成/データの読み取りや書き込みのために、Luaエンジン（100kBのバイナリ）を投入するのが妥当です。