友人と私は、Web サイトのバックエンドに MySQL を使用するか、フラットファイル データベースを使用するかについて議論していました。私は彼に MySQL を使うように言いました。一方、彼はむしろスピードを求めると言った。ファイルの読み取りは、MySQL に接続するよりもはるかに高速であり、彼が正しかったかどうか疑問に思いました。たとえば、次のようにテーブルごとにフォルダを作成しないのはなぜですか。users/ groups/ posts/フォルダ内には ID ( 1、2、3) で名前が付けられたファイルがあり、データには次のような形式を使用します。username: John\npassword: e2fc714c4727ee9395f324cd2e7f331f\nemail: example@example.com
言い換えれば、フラットファイルに対する MySQL の利点は何ですか?
言い換えれば、フラットファイルに対する MySQL の利点は何ですか?
MySQLインデックスと結合 (実行パフォーマンス用)、トランザクション (データ整合性用)、およびSQL(開発パフォーマンス用) を提供します。
あなたのプロジェクトが3-line の自給自足のテキスト ファイルだけを含む場合は、必要ありませんMySQL。
ファイルの読み取りは、MySQL に接続するよりもはるかに高速であり、彼が正しかったかどうか疑問に思いました。
ホブコブル。mySQL のようなデータベースも同様にデータをファイルに保存しますが、多くの最適化、特にインデックス作成機能を備えているため、大きなフラット ファイルの読み取り (または書き込み) に比べてパフォーマンスが大幅に向上します。
非常に限られたケースではフラット ファイルの方が高速な場合がありますが、データベース エンジンは、データ アクセスの高速化と信頼性の向上に取り組んでいる何世代にもわたる開発者の経験を利用しています。たとえば、スクリプトの 2 つのインスタンスがデータベースにデータを書き込もうとした場合の競合状態とロックについて考えてみてください。
使用されるデータ量が CSV ファイルで数行を超える場合、または Wiki のページなどのファイルで簡単に管理できない場合は、データベースを使用してください。複雑なレイヤーが追加されますが、頭痛の種は大幅に軽減されます。
SELECT * FROM posts WHERE MONTH(post_date) = "2010-03-10"フラットファイルですばやく実行することと、それを実現するためにゼロから作成する必要があることを考えてみてください。
「フラットファイルデータベース」とは何ですか? フラット ファイルはフラット ファイルです。名前を付けると、次のようになります。フラット ファイル データベースであると言うと、定義ごとのフラット ファイルにはない、魔法のようにデータベースの機能の一部を備えていると思われます。
フラットファイルに対する MySQL の利点は何ですか?
ここでは MySQL をスキップします。主な質問は、「なぜデータベースを使用するのか」ということです。
パフォーマンス (sewarch 操作 - インデックスは理由があります) を調べて、「ACID 条件」という用語を調べて、データベースが実際に何をするのか漠然とした考えを取得することをお勧めします。
フラット ファイルは何の保証も与えません。何十年にもわたる開発者が、抱えているすべての問題を何度も証明してきました。
もう少しコンテキストが必要です。
あなたの友人が完全なページ（DBに保存された広告「ブロブ」）を読んでいるなら、そうです、MySqlを使用することはあまり役に立ちません。彼が詳細なデータ（ブログの投稿、ニュースアイテム、メタデータを含む画像、注文の詳細など）を持っている場合、サイトが非常に露出度が高く、非常に静的でない限り、ファイルベースのアプローチはすぐに制限されすぎます。
提案したソリューションには2つの大きな欠点があります。
フォルダ/ファイル名を使用することは、各テーブル（この場合はファイル名）にインデックスを1つだけ持つことと同じであるため、他の条件を検索するには時間がかかります。言うまでもなく、1つのディレクトリに多数のファイルがあると、OSに負担がかかり始めます。
その上、URLの一部としてハッシュされたpwdを使用している場合でも、ファイル名によるセキュリティは少しセキュリティ上のリスクがあります。
私は過去にいくつかのファイルシステムベースの中規模アプリケーションを実行しました（要件が誤って管理されていたため、DBを使用できませんでした）。これは楽しいですが、数百のファイルを超えるとすぐに非常に制限されます。そして、たとえ少数であっても、物事が機能し続けることを望むためには、最初からトリックを引き出し始める必要があります。
セキュリティの問題もあります。フラット ファイルを適切に保護しないと、簡単に公開される可能性があります。特にユーザー情報を保存している場合は、フラット ファイルの周りに入力するための障壁はありません。
Web サイトまたはアプリケーションが垂直方向に成長すると仮定すると、フラット ファイルが大きくなるほど読み取りに時間がかかるため、フラット ファイルもスケーリングされません。
そして最後に、データベースを簡単に使用できる場合にフラット ファイルを使用することは、単なるハックです。誰もがデータベースを使用するという点で、「正しい方法」で物事を行っているわけではないので、私は反対のことを主張します.なぜMySQLよりもフラットファイルを使用するのですか? フラットファイルを使用するというあなたの決定を理解または同意するために、他の誰かがあなたのアプリケーションを維持するためにやって来ますか?
ほんの一例: 1,000,000 人の顧客がいて、住所情報があり、NY に住む顧客を検索して設定する必要があるとします。各顧客を個別のファイルに保存した場合、1,000,000 個のファイルすべてを読み取って、顧客が州に属しているかどうかを確認する必要があります。すべてのレコードを 1 つの巨大なファイルに保存した場合、ファイル全体を読み取り、反復して NY のすべての顧客を見つける必要があります。
どちらの場合も、あなたは負けます。
MySql のような RDBMS の場合、いわゆる「セット」操作または SELECT ステートメントを使用し、インデックスを追加すると、エンジンはおそらく NY からすべての顧客を見つけるのに必要なデータよりも 10/20% 多いデータしか読み取ることができません。
お役に立てれば
また、すべてのユーザー情報をPosts/フォルダー内に保存せずに、John Doeによって作成されたすべての投稿をどのように取得しますか（たとえば）。SQLでは、これは単なる結合されたselectステートメントです。フラットファイルの場合、実際の投稿ファイル内に情報を保存するか、コードを記述して自分で結合および検索操作を実行する必要があります。
データの冗長性とアトミック性の欠如は、フラットファイルデータベースの大きな問題であり、保持する必要のあるデータが指数関数的に増え、クエリの遅延や更新/削除/挿入の異常などの他の問題が発生します。
正規化を使用したリレーショナルデータモデルは、アトミック性を確保し、各レコードを一意に識別できるようにし（第1正規形）、テーブルの各フィールドが主キーに機能的に依存していること（第2正規形）と、キーフィールドは、テーブル内の他のフィールドへの一時的な依存関係を共有しません（第3正規形）。
リレーショナルデータモデルは、それを実行する唯一の方法ではなく、おそらく最善ではありませんが、フラットファイルに固有のクエリ遅延と異常の問題に対処しようとします。
Mysql には flatfile と比較していくつかの利点があります。ファイル構造はクエリには適していませんが、ファイル内の CRUD は mysql よりも高速です。mongo db などの SQL を使用しないデータベースを使用して、構造を改善し、速度を向上させることができます。SQL と SQL の間にはいくつかの違いがあります。 no-sqlデータベースですが、flatfileの代わりにno-sql dbを使用する方が良いと思います.bigdataで作業する場合は、no-sql dbの方が確実にsqlよりも優れていることに注意してください..