単一テーブルのリレーショナルデータベースは、単純なNoSQLデータベースに似ていますか？
NoSQLデータベースで推奨される利点の1つは、スキーマがないことです。単一テーブルのリレーショナルデータベースの場合、複数のテーブル間に関係はなく、新しい列を単一のテーブルに簡単に追加できます。スキーマを設計する必要がないため、NoSQLデータベースと同じくらい良いようです。では、単一テーブルのリレーショナルデータベースは単純なNoSQLデータベースに似ていますか？
SQLiteのようなリレーショナルデータベースがより適切にテストされ、おそらくより安定していることを考えると、単一テーブルのリレーショナルデータベースで十分な場合にNoSQLデータベースを使用する十分な理由はありますか？
いいえ-単一テーブルのリレーショナルデータベースは、NoSQLデータベースよりもスプレッドシートに似ています。 NoSQLはnoスキーマを持つことではなく、flexibleを持つことに関するものですスキーマ！
Wikipedia NoSQLと表示されている場合、非常にうまくいきます：
は、リレーショナルデータベースで使用されている表形式のリレーション以外の方法でモデル化されたデータの保存と取得のためのメカニズムを提供します。
ここでのキー（しゃれを許して）の単語はmodeledです。つまり、モデルがあり、それは単なる関係モデルではありません！
余談ですが、記事全体を読む価値は十分にあります-詳細でよく書かれています！
IBM 言う：
「NoSQL」の「いいえ」は「だけではない」の略語であり、実際の単語「いいえ」ではないことを強調することが重要です。多くのNoSQLデータベースがクエリのようなSQLをサポートするだけでなく、マイクロサービスとポリグロットの永続性の世界では、NoSQLとリレーショナルデータベースが1つのアプリケーションで一緒に一般的に使用されるため、この区別は重要です。
そして実際、多くのNoSQLシステム（これらのシステムの多くはオープンソースであるため「ベンダー」と言うのは難しい）は、SQLインターフェースをシステムの上に置くためにスクランブル（またはスクランブル）を行っています。長年にわたってうまく機能しているもの）。
NoSQLと従来のRDBMSについてエッセイ全体を（実際に私が大学で持っているように）書くことができます。このトピックを読むように促す以外に、この方法についてはこれ以上説明しません。
データベースエコスフィアの進化を見るのは魅力的です。新しいSSDチップテクノロジーです。私にとってthe最も興味深い開発は、LSMへの最近の焦点です（- Log Structured Merge tree ）これはNoSQLシステムで広く使用されています NewSQL ones 。私見、これらのNewSQLシステムは未来の道であり、Oracle、SQL Serverなどが見られると期待しています。彼らのパラダイムの多くを採用する（または embrace and extend フレーズを作成するためのそれら）。
繰り返しますが、それは連を書くことができる複雑な技術ですが、 here から：
LSMアルゴリズムの中心はローリングマージプロセスです。LSMツリーは、時間の経過とともに、小規模でより高性能な（しかしより高価な）ストアから、より大きな性能の低い（そしてより安価な）ストアまでデータをカスケードします。
その場で更新する代わりに、データは「チャンク」され、 here から取得されます。
インメモリツリーがしきい値サイズに達すると、新しいインメモリツリーが作成され、古いツリーがディスクに同期されます。ディスクに書き込まれると、ツリーは読み取り専用になりますが、読み取りのコストを削減するために、バックグラウンドで他のディスク上のツリーとマージされます。
あなたはあなたの質問でSQLiteについて言及しています- Key-Value "version" 2012年から2014年の間に開発されたSQLiteです。From here ：
SQLite4から学んだ教訓はSQLite3に組み込まれ、SQLite3は活発に維持および開発され続けています。このリポジトリは履歴レコードとして存在します。現時点では、SQLite4の開発を再開する予定はありません。
最後の言葉は Brian Aker 、MySQLの元アーキテクチャディレクター、NoSQLの面白さを示し、YouTubeで公開 here 。彼の見解は、その講演中に彼が発表した漫画によって要約することができると思います。
興味深い質問に+1して（閉じられないことを願っています！）、フォーラムにようこそ！
はい、単一テーブルのリレーショナルデータベースをNoSQLデータベースのように使用できます。スプーンを使って家をペイントすることもできます。
意図したとおりにツールを使用する必要があります。それ以外の場合は、ツールと、ツールを使用して解決しようとしている問題の両方を解決します。正規化が必要でデータ異常がない場合は、多くのテーブルが存在する可能性があります。すべての論理エンティティタイプを単一の物理テーブルにプッシュすると、列が多くなり（すべてのDBMSに制限があります）、DRIと同様に、列のほとんどがnullになり、クエリが悪夢になります。これらのすべての値をJSONまたはXML列に押し込むことができます。すべての細断処理がアプリケーションで発生する場合は、Key-Valueストアを考案したばかりです。 DBMSがクエリを実行すると予想される場合は、スキーマのないパーサーのふりをしているSQLパーサーのふりをしているツリーパーサーがあります。とにかくパフォーマンスが必要な人。
さて、私のペイントスプーンはどこにありますか。
最も基本的には、NoSQLシステムはexactly2つのフィールドを持つ単一のテーブルです：制限された長さkeyフィールド、およびより大きい「一般的な」値フィールド。通常はjsonを保持しますが、jsonの代わりにバイナリデータ（画像や他のファイルなど）または他のオブジェクト表記も保持する場合があります。
ただし、これが失敗するポイントは3つあります。
最初に、私はこの声明を見ます：
"単一テーブルのリレーショナルデータベースの場合、複数のテーブル間に関係はなく、新しい列を単一のテーブルに簡単に追加できます。"
新しい列を必要に応じてこのようなテーブルに簡単に追加できるという考えは、長くは続かないでしょう。代わりに、個々のレコードはvalueフィールドの単一の（複雑な）エントリであることが多く、多くの場合json形式です。
次に、正確なキーで検索するのではなく、NoSqlシステムでは、キーが何らかのパターンに一致するレコードのセットを取得できることがよくあります。このパターンマッチングは、リレーショナルデータベースではあまり一般的ではなく、存在する場合、インデックスのパフォーマンスに関しては十分にサポートされない可能性があります。
3番目に、ほとんどのNoSqlデータストアは、これらの複雑なjson値をピアリングする機能を提供します。機能は限られていますが、リレーショナルデータベースで見つかるはずのものよりもはるかに優れています。パターンとに一致するすべてのキーの値のセットを取得するなどの操作を行うことができます。これらのフィールドのjsonプロパティの値はいくつかの基準を満たします。 、または特定のキーに一致するレコードを更新します。レコード内の単一のjsonプロパティの値のみを変更します。
ここでは例としてJSONを使用しましたが、レコードの内部スキーマの他のメカニズムを使用またはサポートするいくつかの異なる製品で、JSONに限定されていません。