データをディスクに保存するだけでなく、データベースを使用する理由は何ですか？

データベースの代わりに、データをJSONにシリアル化し、必要に応じて保存してディスクにロードします。すべてのデータ管理はプログラム自体で行われ、SQLクエリを使用するよりも速くて簡単です。そのため、なぜデータベースが必要なのか理解できませんでした。

データをディスクに保存するだけでなく、データベースを使用する必要があるのはなぜですか？

1. データベースのデータを照会できます（質問をしてください）。
2. データベースからデータを比較的迅速に検索できます。
3. JOINを使用して、2つの異なるテーブルのデータを関連付けることができます。
4. データベース内のデータから意味のあるレポートを作成できます。
5. データには構造が組み込まれています。
6. 特定のタイプの情報は常に1回だけ保存されます。
7. データベースはACIDです。
8. データベースはフォールトトレラントです。
9. データベースは非常に大きなデータセットを処理できます。
10. データベースは並行しています。データを破損することなく、複数のユーザーが同時にそれらを使用できます。
11. データベースはうまく拡張できます。

要するに、あなたは長年にわたって非常に頭の良い人々によって開発された、広く知られた実績のあるテクノロジーの恩恵を受けることができます。

データベースが過剰であることが心配な場合は、SQLiteをチェックしてください。

ロバートが言ったことにはすべて同意しますが、データをディスクに保存するだけでなく、いつデータベースを使用すべきかを教えてくれませんでした。

したがって、スケーラビリティ、信頼性、フォールトトレランスなどについてロバートが言ったことに加えて、これを理解してください。

RDBMSをいつ使用するかについて、考慮すべき点がいくつかあります。

• リレーショナルデータがあります。つまり、製品を購入する顧客がいて、それらの製品にはサプライヤーとメーカーがいる
• 大量のデータがあり、関連情報をすばやく見つけることができる必要がある
• 識別された以前の問題、スケーラビリティ、信頼性、ACIDコンプライアンスについて心配する必要があります。
• ビジネス上の問題を解決するには、レポートツールまたはインテリジェンスツールを使用する必要があります

NoSQLをいつ使用するか

• 構造化されていない多くのデータを保存する必要がある
• スケーラビリティと速度のニーズ
• 通常、スキーマを事前に定義する必要はありません。そのため、要件が変更されている場合、これは良い点です。

最後に、ファイルを使用する場合

• ファイルシステムが処理できる合理的な量の非構造化データがある
• あなたは構造、関係を気にしません
• スケーラビリティや信頼性は気にしません（ただし、これらはファイルシステムに応じて実行できます）
• データベースが追加するオーバーヘッドを望んでいない、または処理できない
• ファイルシステムに属する構造化されたバイナリデータを処理しています。たとえば、画像、PDF、ドキュメントなどです。

誰も言及していないと思われることの1つは、レコードのインデックス作成です。現時点でのアプローチは問題ありません。非常に小さなデータセットがあり、それにアクセスする人はほとんどいないと思います。

複雑になるにつれて、実際にデータベースを作成しています。呼び出したいものは何でも、データベースはディスクに保存されたレコードのセットです。ファイルを作成しているのか、MySQL、SQLite、またはファイルを作成しているのが何であれ、どちらもデータベースです。

不足しているのは、データベースシステムに組み込まれている複雑な機能です。

頭に浮かぶ主なものは、インデックス作成です。シリアル化された配列、またはJSON文字列に10または20、さらには100または1000のレコードを保存し、ファイルから引き出して比較的迅速に反復処理することができます。

ここで、10,000、100,000、または1,000,000のレコードがあるとします。誰かがログインしようとすると、数百メガバイトのファイルを開いてプログラムのメモリにロードし、同様のサイズの情報の配列を引き出してから、何十万ものレコードを反復してアクセスする1つのレコードを見つけます。

適切なデータベースを使用すると、レコード内の特定のフィールドにインデックスを設定して、データベースにクエリを実行し、巨大なデータセットでも非常に迅速に応答を受け取ることができます。Memcachedのようなもの、または自作のキャッシングシステム（たとえば、検索結果を別のテーブルに10分間保存し、他の誰かがすぐに同じものを検索した場合にそれらの結果をロードする）と組み合わせます。手動でファイルの読み取り/書き込みを行っている場合、このような大規模なデータセットでは得られない非常に高速なクエリが発生します。

索引付けに大まかに関連するもう1つのことは、情報の転送です。上で述べたように、数百または数千メガバイトのファイルがある場合、その情報をすべてメモリにロードし、手動で（おそらく同じスレッドで）繰り返し、データを操作する必要があります。

データベースシステムでは、独自のスレッドで実行されるか、独自のサーバーで実行されます。プログラムとデータベースサーバー間で送信されるのはSQLクエリのみであり、送信されるのはアクセスするデータのみです。データセット全体をメモリにロードするのではなく、送信および受信するのは、データセット全体のごく一部です。

質問のコメントで記述しているもののリストのような単純なデータがある場合、SQLデータベースではあまり得られません。時間の経過とともにデータがより複雑になる可能性があることを知っているため、多くの人々が今でもそれらを使用しています。

ただし、単純なリストをロードし、メモリに保持し、必要なときに書き込むだけでも、多くの問題が発生する可能性があります。

プログラムの異常終了はデータを失う可能性があります。または、ディスクへのデータの書き込み中に何かがおかしくなり、ファイル全体を強制終了する可能性があります。独自のメカニズムを使用してこれを処理することもできますが、データベースでは、戦闘で実証済みの手法を使用してこれを処理します。

データが大きくなりすぎて頻繁に更新され始めると、すべてのデータのシリアル化と保存が大きなリソースを浪費し、すべてが遅くなります。あなたは物事を分割する方法を考え出す必要がありますので、それほど高価ではありません。データベースは、フォールトトレラントな方法でディスクに変更されたものだけを保存するように最適化されています。また、これらは設計されているため、必要なデータをいつでもすぐにロードできます。

また、SQLデータベースを使用する必要はありません。多くの人が使用しているNoSQL「データベース」を使用できます。JSONを使用してデータを保存するだけです。しかし、それはフォールトトレラントな方法で行われ、データをインテリジェントに分割、クエリ、および複数のコンピューターにインテリジェントに分割できるようにします。

また、一部の人々は物事を混乱させます。ログイン情報を保存するために、RedisなどのNoSQLデータストアを使用する場合があります。次に、リレーショナルデータベースを使用して、より興味深いクエリを実行する必要があるより複雑なデータを保存します。

多くの回答が並行性と信頼性の問題に焦点を合わせていると思います。データベースには、同時実行性、信頼性、パフォーマンスのほかに他の利点があります。これらは、バイトと文字がメモリ内でどのように表されるかを気にしないようにします。言い換えれば、データベースを使用すると、プログラマーは「方法」ではなく「内容」に集中できます。

回答の1つはクエリに言及しています。「SQLデータベースへの質問」は、質問の複雑さに合わせて調整できます。開発中にコードが進化するにつれて、「すべてをフェッチ」などの単純なクエリは、「property1がこの値に等しいすべてをフェッチし、property2で並べ替え」に簡単に拡張できます。特定のプロパティのインデックスを作成することで、ほとんどのクエリのパフォーマンスを高速化できます。

他の利点は関係です。クエリを使用すると、さまざまなデータセットのデータを相互参照して、ネストされたループを作成する方が簡単です。たとえば、ユーザーと投稿が異なるデータセット（またはDBテーブルまたはJSONオブジェクト）であるシステムで3未満の投稿を持つユーザーからのすべてのフォーラム投稿の検索は、読みやすさを犠牲にすることなく1つのクエリで実行できます。

全体的に、SQLデータベースは、データボリュームが大きくなる可能性がある場合（たとえば1000個を超えるオブジェクト）、データの異なるサブセットへのコードアクセスの重要な異なる部分でのデータアクセスの場合、プレーン配列よりも優れています。

TLDR

アプリケーションに対して本質的に有効な短期のデータストア技術的決定を下したようです。カスタムデータストア管理ツールを作成することにしました。

いずれかの方向に移動するオプションを備えた連続体に座っています。

長期的には（ほぼ100％とは限りませんが）トラブルに直面する可能性があり、既存のデータストアソリューションの使用に変更したほうがよいでしょう。特定の非常に一般的な予測可能なパフォーマンスの問題に対処せざるを得ないため、独自のツールを使用するよりも、既存のツールを使用した方がよいでしょう。

アプリケーションに組み込まれ、直接使用される（小さな）カスタム目的のデータベースを作成したようです。OSとファイルシステムに依存して実際のディスクの書き込みと読み取りを管理し、その組み合わせをデータストアとして扱っていると思います。

あなたがしたことをするとき

あなたはデータストレージのスイートスポットに座っています。OSおよびファイルシステムのデータストアは、信じられないほど便利でアクセスしやすく、クロスプラットフォームで移植可能です。この組み合わせは長い間存在しており、ほぼすべての標準的な展開構成でサポートされ、アプリケーションを実行することが確実です。

それはまたのためにコードを書くための簡単な組み合わせだ- APIは、かなりストレートフォワードおよび基本であり、それは、それが働いて得るために、コードの比較的少数のラインを取ります。

一般的に、次の場合に行ったことを行うことが理想的です。

• 新しいアイデアのプロトタイピング
• 拡張する必要性が非常に低い、パフォーマンス面でのアプリケーションの構築
• データベースをインストールするためのリソースの不足など、異常な状況による制約

代替案

連続したオプションがあり、ここから移動できる2つの「方向」があります。私が考える「ダウン」と「アップ」です。

ダウン

これは適用する可能性が最も低いオプションですが、完全を期すためにここにあります。

必要に応じて、ダウンできます。つまり、OSとファイルシステムを完全にバイパスして、実際にディスクから直接読み書きできます。この選択は通常、極端な効率が必要な場合にのみ関連します。たとえば、完全に機能するOSに十分なRAMがない、最小/小型のMP3プレーヤーデバイス、または非常に効率的な質量を必要とするWayback Machineなどデータの書き込み操作（ほとんどのデータストアは、ほとんどすべてのアプリケーションで圧倒的に一般的なユースケースであるため、低速の書き込みと高速の読み取りをトレードオフします）。

アップ

ここにはいくつかのサブカテゴリがあります-これらは完全に排他的ではありません。いくつかのツールは両方に対応し、それぞれにいくつかの機能を提供し、あるモードでの動作から別のモードでの動作に完全に切り替えることができます。

より強力なデータストア

データ操作の複雑さを管理するために独自のアプリケーションに依存しながら、ますます大量のデータを保存する必要がある場合があります。さまざまなキーバリューストアを利用でき、関連する機能をさまざまな範囲でサポートしています。NoSQLツールは、他のツールと同様にこのカテゴリに分類されます。

これは、以下がアプリケーションを説明するときにスケールアップする明らかなパスです。

• 異常に重い読み取り依存
• 高いパフォーマンスと低い（短期）一貫性保証とのトレードオフで問題ありません（多くの場合 "最終的な一貫性"を提供します）。
• ほとんどのデータ操作と一貫性の欠如を「直接」管理します（実際には、最初はサードパーティのツールを使用することになりますが、最終的にこれをアプリケーションまたはカスタム記述中間層に持ち込みます） 。
• 「比較的単純な」データ操作要件を使用して、保存するデータの量および/またはそのデータを検索する能力を大幅に拡大したいと考えています。

ここには多少のゆらぎの余地があります-読み取りの速度を落とすために、読み取りの一貫性を向上させることができます。さまざまなツールとオプションが、データ操作API、インデックス作成、その他のオプションを提供します。これらは、特定のアプリケーションを簡単に作成するのに適している場合があります。したがって、上記のポイントがアプリケーションをほぼ完全に説明している場合、より強力なデータストアソリューションを使用するのに「十分近い」可能性があります。

よく知られた例：CouchDB、MongoDB、Redis、MicrosoftのAzureのようなクラウドストレージソリューション、Google App Data Store、AmazonのECE。

より複雑なデータ操作エンジン

「SQL」ファミリーのデータストレージアプリケーションは、他のさまざまなアプリケーションと同様に、純粋なストレージエンジンよりもデータ操作ツールとしてよりよく説明されています。これらは、データのストレージを超えて、多くの場合、物事のキーバリューストア側で利用可能なものを超えて、幅広い追加機能を提供します。次の場合にこのパスを使用します。

• パフォーマンスが低下することを意味する場合でも、読み取りの一貫性が絶対に必要です。
• 非常に複雑なデータ操作を効率的に実行したい-非常に複雑なJOINおよびUPDATE操作、データキューブ、スライスなどを考えてください...
• 剛性とパフォーマンスのトレードオフで問題ありません（簡単に、かつ/または効率的に変更できない、テーブルなどの強制的な固定データストレージ形式を考えてください）。
• 多くの場合、より複雑なツールとインターフェイスのセットに対処するためのリソースがあります。

これは、データベースまたはデータストアの思考のより「伝統的な」方法であり、はるかに長いの周りされている-ので、そこにあるたくさんここで入手可能だ、とに対処するための複雑さの多くは、しばしばあります。ただし、ある程度の専門知識と知識が必要であり、シンプルなソリューションを構築し、複雑さの多くを回避しますが、ほとんどの場合、サードパーティのツールとライブラリを使用してそのほとんどを管理することになります。

よく知られている例は、MySQL、SQL Server、Oracleのデータベース、およびDB2です。

仕事を外部委託する

いくつかの最新のサードパーティツールとライブラリがあり、データストレージツールとアプリケーションの間に介在して、複雑さを管理しやすくしています。

データストアの管理と操作にかかる作業の大部分またはすべてを最初に取り除こうとし、理想的には、必要な場合にのみ複雑性にスムーズに移行できるようにします。これは起業家精神と研究の活発な分野であり、いくつかの最近の結果はすぐにアクセスして使用できます。

よく知られている例は、MVCツール（Django、Yii）、Ruby on Rails、およびDatomicです。文字通り、さまざまなデータストアのAPIのラッパーとして機能するツールおよびライブラリが多数あるため、ここで公平を期することは困難です。

PS：ビデオをテキストよりも好む場合は、Rich Hickeyのデータベース関連のビデオをいくつか見たいかもしれません。彼は、データストアの選択、設計、使用に関する考え方のほとんどを明確に説明しています。

ファイルシステムはNoSQLデータベースの説明に適合しているため、ここでいくつかの答えが示唆しているように、データを保存する方法を決定するとき、RDBMSを優先してそれを破棄するのではなく、NoSQLデータベースの説明を使用することを必ず検討する必要があると思います。

ファイルシステム（および一般にNoSQL）の1つの問題は、データ間の関係を処理することです。それがここでの主要なブロッカーではない場合、私は今のところRDBMSをスキップすると言うでしょう。また、ファイルシステムをストレージとして使用することのプラス面も覚えておいてください。

• ゼロ管理
• 複雑さが低く、セットアップが簡単
• オペレーティングシステム、言語、プラットフォーム、ライブラリなどに対応
• 構成設定のみがディレクトリです
• テストするのは簡単
• 既存のツール、バックアップ、変更などで調べるのは簡単
• 優れたパフォーマンス特性とオペレーティングシステムによる適切な調整
• 開発者が理解しやすい
• 依存関係なし、追加のドライバーなし
• セキュリティモデルは理解するのは簡単であり、オペレーティングシステムの基本部分です。
• データは外部からアクセスできません

（ソース）

ファイルシステムはデータベースの一種です。他の人が言っているようなRDBMSではなく、厳密な意味でのDBであることは確かです。ルックアップデータ（ファイルの内容）にキー（ファイル名）を提供します。このデータには、ストレージを抽象化し、プログラムが通信するためのAPIがあります。

したがって、データベースを使用しています。他の投稿では、さまざまな種類のデータベースの長所について議論することができます...

データを変更する複数のプロセス（ユーザー/サーバー）がある場合、データベースが必要です。次に、データベースは、それらが互いの変更を上書きするのを防ぐのに役立ちます。

データがメモリよりも大きい場合にもデータベースが必要です。現在、使用可能なメモリがあるため、多くのアプリケーションでデータベースを使用することは実際には時代遅れになっています。

あなたのアプローチは、「インメモリデータベース」のナンセンスよりも間違いなく優れています。これは本質的にあなたのアプローチですが、多くのオーバーヘッドが追加されます。

特定のアプリケーションでRDBMSが必要かどうかを常に自問する必要があります。最初に必要なすべてのツールとフレームワークを自動的に想定する設計プロセスで構築されたアプリケーションが多すぎます。リレーショナルデータベースは非常に一般的であり、多くの開発者が以前と同様のアプリケーションに取り組んできたため、プロジェクトが開始される前に自動的に組み込まれます。多くのプロジェクトでこれを回避できますので、あまり厳しく判断しないでください。

これなしでプロジェクトを開始しましたが、動作します。これは、SQLを実行するまで待たずに簡単に実行できます。それには何の問題もありません。

このプロジェクトが拡大し、要件がより複雑になるにつれて、構築が困難になるものもあります。代替方法を調査してテストするまで、どちらが優れているかをどのように知るのですか？あなたはプログラマーに頼み、炎をかき分け、この質問に答えるのは「依存する」ことができます。一度学習すれば、データベースの利点の一部を処理するために、言語で何行までコードを記述できるかを検討できます。ある時点で、あなたは車輪を再発明しています。

簡単はしばしば相対的です。ユーザーがコードを記述することなく、Webページを構築し、フォームをデータベーステーブルに接続できるフレームワークがいくつかあります。マウスで苦労している場合、これは問題になる可能性があります。誰もが知っていることですが、これはスケーラブルでも柔軟でもありません。なぜなら、すべてをGUIに密結合することを禁じているからです。非プログラマーがプロトタイプを作成しました。ここにたくさんのYAGNIがあります。

SQLを学習する代わりに、選択した言語で操作されるORMを学習したい場合は、それを選択しますが、SQLを使用して、インストール、テーブルの作成、人気のあるデータベースからのデータの抽出を試みます（Select * From; is not驚異的なもの）。簡単です。そもそも誰かがそれらを作成した理由です。十分な情報に基づいた意思決定を行うために、これほど大きな投資が行われているようには見えません。おそらくパフォーマンステストも行うことができます。

ディスクにデータを保存すると、ISは、ファイルの名前はレコードのキーであることで、独自のファイル内の各オブジェクトを置く場合は特に、データベースに書き込みます。また、ファイルを読み取るためのルックアップ時間を最小限に抑えるには、キーの最初の数文字に基づいてサブディレクトリを作成します。

たとえば、key = ghostwriterはg / ho / stwriter.jsonまたはg / h / o / stwriter.jsonまたはg / ho / ghostwriter.jsonまたはg / h / o / ghostwriter.jsonに移動します。キーの配布に基づいて命名スキームを選択します。シーケンス番号の場合、5/4/3 / 12345.jsonは他の方法よりも優れています。

それはデータベースであり、必要なことをすべて実行する場合は、そのようにします。今日では、それはGDBMやBerkeley dbのようなNoSQLデータベースと呼ばれます。たくさんの選択肢。最初に必要なものを把握してから、詳細を処理するためのインターフェイスライブラリ（memcachedなどのget / setインターフェイスまたはCRUDインターフェイス）を構築します。次に、データベース形式を変更する必要がある場合はライブラリを交換できます異なる特性を持つ。

PostgreSQLやApache Derby DBなどの一部のSQLデータベースでは、独自のデータベースを含む多くのNoSQL形式の上でSQLクエリを実行できることに注意してください。MyBatisについてはわかりませんが、似ているかもしれません。

NoSQLの誇大広告は避けてください。機能について読み、パフォーマンスと機能をテストしてから、アプリケーションのニーズにどれだけ一致するかに基づいて選択します。

http://www.hdfgroup.org/HDF5/は、人々があまり考えない、もう1つの興味深い広く使用されているデータストア形式です。

データが同時に更新されるとすぐに、データベース（メモリ内のデータベースである可能性があります）を使用するアプローチがより正確でパフォーマンスが向上する可能性があります。同時更新、トランザクション、キャッシュ、非同期I / Oなどを心配する必要があります。

ここに投稿しているようなQAを保存/取得するにはデータベースが必要です！単純なファイルでは、さまざまなトピックに関連するデータを整理できません。