リレーショナルデータベースを使用すべきでないのはいつですか？
Google/bigtableシナリオを除いて、いつリレーショナルデータベースを使用するべきではありませんか？なぜそうではなく、何を使うべきですか？ （「難しい方法」を学びましたか？）
私の経験では、次の基準のいずれかに該当する場合は、リレーショナルデータベースを使用しないでください。
- データが任意の深さの階層またはグラフ（ネットワーク）として構造化されている
- 典型的なアクセスパターンは、書き込みよりも読み取りを強調します。
- アドホッククエリの要件はありません。
深い階層とグラフは、リレーショナルテーブルにうまく変換できません。 OracleのCONNECT BYのような独自の拡張機能の支援があっても、ツリーを追跡するのはSQLを使用するのに非常に困難です。
リレーショナルデータベースは、単純な読み取りアクセスに多くのオーバーヘッドを追加します。トランザクションと参照の整合性は強力ですが、一部のアプリケーションには過剰です。したがって、読み取りがほとんどのアプリケーションでは、ファイルのメタファーで十分です。
最後に、予期しないクエリが予想されない場合は、本格的なクエリ言語を使用したリレーショナルデータベースは必要ありません。 「東海岸で販売員によってグループ化された、5％割引の青いウィジェットをいくつ販売したか」などの質問をするスーツがない場合、あなたは、あなたがたはDBなしで生きることができません。
リレーショナルデータベースのパラダイムでは、データの使用についていくつかの仮定を行います。
- リレーションは、順序付けられていない行のセットで構成されます。
- リレーション内のすべての行には、同じ列のセットがあります。
- 各列には固定の名前とデータ型があり、すべての行に意味があります。
- リレーションの行は、主キー列の一意の値によって識別されます。
- 等.
これらの仮定は、ある程度の柔軟性を犠牲にして、単純さと構造をサポートします。すべてのデータ管理タスクがこの種の構造に適合するわけではありません。たとえば、複雑な属性や可変属性を持つエンティティはそうではありません。リレーショナルデータベースソリューションでサポートされていない領域に柔軟性が必要な場合は、別の種類のソリューションを使用する必要があります。
さまざまな要件でデータを管理するための他のソリューションがあります。たとえば、セマンティックWebテクノロジでは、メタデータをデータと同じように属性として扱うことにより、各エンティティが独自の属性を定義し、自己記述型にすることができます。これは、リレーショナルデータベースによって課される構造よりも柔軟性がありますが、その柔軟性にはそれ自体のコストが伴います。
全体として、各ジョブに適切なツールを使用する必要があります。
「 次世代データベース 」に対する他の回答も参照してください。
3つの主要なデータモデル（C.J.Date、E.F.Codd）があり、これにフラットファイルを追加しています。
- フラットファイル（構造はさまざまです-「愚かな」フラットテキストから文法に準拠したファイルまで、巧妙なツールと組み合わせて非常に巧妙なことを行い、コンパイラーとそれらができることを考え、新しいもののモデリングにおけるアプリケーションを狭めます）
- hierarchical （ツリー、ネストされたセット-例：xmlと他のマークアップ言語、レジストリ、組織図など;あらゆるものをモデル化できますが、整合性ルールは簡単に表現できず、取得を自動的に最適化することは困難です。一部の検索は高速で、一部は非常に遅いです）
- ネットワーク （ネットワーク、グラフ-例：ナビゲーションデータベース、ハイパーリンク、セマンティックウェブ、ほとんどすべてをモデル化できますが、検索の自動最適化は問題です）
- relational （一次述語論理-例：リレーショナルデータベース、検索の自動最適化）
階層とネットワークの両方をリレーショナルで表すことができ、リレーショナルは他の2つで表すことができます。
リレーショナルが「より良い」と見なされる理由は、データ検索言語だけでなく、 stable でバックアップされた強力な宣言的データ整合性を含むデータ定義言語でも、宣言的な性質と標準化にあり、スケーラブルです、マルチユーザー管理システム。
利点にはコストが伴いますが、ほとんどのプロジェクトは、長期的なデータを格納するシステム（マルチアプリケーション）が適切な比率であり、近い将来に使用可能になると考えています。
システムを構築するのではなく、単一のアプリケーション（おそらく単一のユーザー向け）を構築していて、データを使用する複数のアプリケーションも複数のユーザーも必要としないことがかなり確実である場合は、すぐにおそらくより高速なアプローチが見つかるでしょう。
また、格納するデータの種類とそのモデル化方法がわからない場合は、リレーショナルモデルの長所が無駄になります。
または、単にデータの整合性をそれほど気にしない場合（これは問題ありません）。
すべてのデータ構造は特定の用途に最適化されており、適切にモデル化されて意味的に偏りのない方法で「現実」を表現しようとする場合にのみ関係があります。リレーショナルデータベースでの経験が悪かった人は、通常、他のタイプのデータモデルでは経験がはるかに悪くなることを理解していません。恐ろしい実装が可能であり、特にリレーショナルデータベースを使用すると、複雑なモデルを比較的簡単に作成できるため、かなりの怪物を手にしてしまう可能性があります。それでも、XMLで同じモンスターを想像しようとすると、いつも気分がよくなります。
IMOの優れたリレーショナルモデルの1つの例は、SQLに関連する問題の複雑さと短さの比率です。
High Scalability blog にアクセスすることをお勧めします。このブログでは、ほぼ毎日このトピックについて説明しており、RDMBSを介して分散ハッシュなどを選択したプロジェクトに関する記事が多数あります。
迅速な（しかし、非常に不完全な答え）は、すべてのデータが効率的にテーブルにうまく変換されるわけではないということです。たとえば、データが基本的に1つの大きな辞書である場合、おそらく古いRDBMSよりもはるかに高速な代替手段があります。そうは言っても、それは主にパフォーマンスの問題であり、パフォーマンスがプロジェクトで大きな懸念事項ではなく、たとえば安定性、一貫性、信頼性などがそうである場合、これらのテクノロジーを深く掘り下げることにはあまり意味がありません。 RDBMSは、すべての言語とプラットフォームでサポートされ、豊富なソリューションから選択できる、はるかに成熟した十分に開発されたスキームです。
15年前、私は信用リスクシステム（基本的には大きなツリーウォーキングシステム）に取り組んでいました。 HPUXとsolarisでSybaseを使用していて、パフォーマンスが私たちを殺していました。私たちは、Sybaseから直接行うことのできないコンサルタントを雇いました。次に、OOデータベース（この場合はオブジェクトストア））に切り替えて、パフォーマンスが約100倍向上しました（コードも約100倍簡単に記述できました）。
しかし、そのような状況は非常にまれです。リレーショナルデータベースが最初の選択肢として適しています。
スキーマが大きく異なると、リレーショナルデータベースで苦労します。ここで、XMLデータベースまたはキーと値のペアのデータベースが最適に機能します。または、IBM DB2を使用して、リレーショナルデータとXMLデータの両方を単一のデータベースエンジンで管理することもできます。
約7〜8年前に、当初の期待を超えて人気が高まるWebサイトに取り組み、パフォーマンス面で問題を抱えました。私たちは皆、Webベースのプロジェクトに比較的経験が浅いため、通常のデータベースの個別のサーバーへの分離、ロードバランシングなどをどうするかについて、大きな負担となりました。
ある日、私はかなり単純なことを考えました。サイトはユーザーに基づいているため、ユーザーのプロファイルは、ユーザーID、多くの情報変数などの通常の方法でデータベーステーブルに保存され、他のユーザーが検索できるユーザープロファイルページとして表示されます。 。私はそのすべてのデータを単純なhtmlファイルにフラッシュしました。既にユーザープロファイルページとして準備されており、大幅に向上しました-基本的にはキャッシュです。ユーザーがプロファイル情報を編集したときに、元のhtmlファイルを解析して編集用に配置し、htmlをファイルシステムにフラッシュバックするシステムを作成しました。
ユーザーがお互いに送信するメッセージを同じように作りました。基本的に、システムにデータベースを完全にバイパスさせ、INSERTまたはUPDATEを回避できるところならどこでも、大幅に向上しました。それは常識のように聞こえるかもしれませんが、それは啓発的な瞬間でした。リレーショナルセットアップ自体の回避ではありませんが、データベース全体の回避です-KISS。