非リレーショナルDBから始めたばかりで、まだ頭を抱えて、どのモデルが最適かを考えています。そして、私はCouchDBについてのみ話すことができます。
それでも、いくつかの予備的な結論があります。
非リレーショナルの世界でよりうまく機能する代替設計を思いついたか。
設計の焦点がシフトします。ドキュメントモデル（DBテーブルに対応）の設計はほとんど無関係になり、すべてはビュー（クエリに対応）の設計にかかっています。
ドキュメントDBは一種の複雑さを交換します。SQLには柔軟性のないデータと柔軟なクエリがあり、ドキュメントDBはその逆です。
CouchDBモデルは「JSONドキュメント」（基本的にネストされたハッシュテーブル）のコレクションです。各ドキュメントには一意のIDがあり、IDで簡単に取得できます。その他のクエリの場合は、「ビュー」を記述します。これは、map / reduce関数の名前付きセットです。ビューは、キー/値のペアのリストとして結果セットを返します。
コツは、SQLデータベースにクエリを実行するという意味ではデータベースにクエリを実行しないことです。ビュー関数の実行結果はインデックスに保存され、インデックスのみをクエリできます。（「すべてを取得」、「キーを取得」、または「キー範囲を取得」として。）
SQLの世界で最も類似しているのは、ストアドプロシージャを使用してのみDBにクエリを実行できる場合です。サポートするすべてのクエリは事前定義する必要があります。
ドキュメントのデザインは非常に柔軟です。私はたった2つの制約を見つけました：
- 結合に対応するものがないため、関連するデータを同じドキュメントにまとめます。
- ドキュメントを大きくしすぎて頻繁に更新されないようにしてください（たとえば、1年間のすべての会社の売上を同じドキュメントに入れるなど）。ドキュメントが更新されるたびに再インデックスが実行されるためです。
しかし、すべてはビューの設計にかかっています。
SQLデータベースよりもCouchDBを使用した方が作業レベルがストレージレベルではなくシステムレベルであることがわかった代替設計。データがあり、それらをWebページに提供したい場合、システム全体の複雑さが少なくとも50％削減されます。
- DBテーブルの設計なし （軽微な問題）
- ODBC / JDBC中間層はなく、すべてのクエリとhttp経由のトランザクション （中程度の問題）
- JSONからの単純なDBからオブジェクトへのマッピング。これはSQLの同じものと比較してほとんど取るに足らない 重要（重要です！）
- AJAXを使用してブラウザーによって直接取得されるようにドキュメントを設計し、HTMLとして表示される前にJavaScriptの改善を少し追加できるため、アプリケーションサーバー全体をスキップする可能性があります。（巨大！！）
通常のWebアプリケーションの場合、ドキュメント/ JSONベースのDBは大きな利点であり、クエリの柔軟性が低く、データ検証のための追加のコードがいくつかあるという欠点は、わずかな代償であるように見えます。
不可能と思われるものに頭をぶつけましたか？
未だに。データベースをクエリする手段としてのMap / Reduceはなじみがなく、SQLを書くよりも多くのことを考える必要があります。プリミティブの数はかなり少ないため、必要な結果を得るには、主に、キーの指定方法を工夫することが重要です。
クエリは2つ以上のドキュメントを同時に見ることができないという制限があります。結合や他の種類のマルチドキュメントリレーションシップはありませんが、これまで克服できないものはありません。
制限の例として、カウントと合計は簡単ですが、平均はCouchDBビュー/クエリでは計算できません。修正：合計とカウントを個別に返し、クライアントで平均を計算します。
たとえば、あるパターンから別のパターンに変換するなど、設計パターンでギャップを埋めましたか？
それが可能かどうかはわかりません。これは、機能的なスタイルのプログラムをオブジェクト指向のスタイルに変換するような、完全な再設計のようなものです。一般に、SQLテーブルよりもドキュメントの種類がはるかに少なく、各ドキュメントに含まれるデータの数も多くなります。
それを考える1つの方法は、SQLで挿入と一般的なクエリを確認することです。たとえば、顧客が注文すると、どのテーブルと列が更新されますか？そして、月次売上レポートのどれですか？その情報はおそらく同じドキュメントに入れるべきです。
つまり、クエリを簡略化するために必要に応じてフィールドが複製された、顧客IDと製品IDを含む注文用の1つのドキュメントです。ドキュメント内のすべてのものは簡単に照会できます。たとえば、注文と顧客の間の相互参照が必要なものはすべてクライアントが実行する必要があります。したがって、地域ごとの売上に関するレポートが必要な場合は、地域コードを注文に含める必要があります。
現在、明示的なデータモデルを実行していますか（UMLなど）？
申し訳ありませんが、ドキュメントDBの前にUMLをあまり実行していません:)
しかし、どのフィールドがどのドキュメントに属し、どのような種類の値が含まれるかを示すある種のモデルが必要です。後で参照するためと、DBを使用するすべての人が規則を知っていることを確認するための両方です。たとえば、テキストフィールドに日付を保存してもエラーは発生せず、誰でも好きなようにフィールドを追加または削除できるため、検証コードと慣習の両方が必要です。特に外部リソースを使用している場合。
RDBMSが提供する主要な追加サービスのどれかを見逃していますか？
いいえ。しかし、私のバックグラウンドはWebアプリケーション開発者です。私たちはデータベースを必要な範囲でのみ扱います:)
私が以前働いていた会社が、複数のベンダーのSQLデータベースで実行するように設計された製品（webapp）を作成しました。「追加サービス」はDBごとに非常に異なるため、DBごとに個別に実装する必要がありました。そのため、RDBMSから機能を移動する作業が減りました。これは全文検索にも拡張されました。
だから、あきらめているものは何でもそもそも私が本当に持っていなかったものです。明らかに、あなたの経験は異なる場合があります。
注意：私が現在取り組んでいるのは、財務データ、株価情報などのWebアプリケーションです。これはドキュメントDBに非常によく一致します。私の観点から見ると、手間をかけずにDBのすべての利点（永続性とクエリ）を得ることができます。
しかし、これらのデータは互いにかなり独立しており、複雑なリレーショナルクエリはありません。ティッカーによる最新の見積もりの取得、ティッカーと日付範囲による見積もりの取得、会社のメタ情報の取得など、ほとんどすべてです。私が見たもう1つの例はブログアプリケーションで、ブログは非常に複雑なデータベーススキーマによっても特徴付けられていません。
私が言おうとしているのは、私が知っているドキュメントDBの成功したアプリケーションはすべて、そもそもドキュメント（Google検索の場合）、ブログ投稿、ニュース記事、財務データなど、あまり相互関係のないデータであったということです。 。
ドキュメントモデルよりもSQLに適切にマップするデータセットがあると思います。そのため、SQLは存続すると思います。
しかし、データを格納および取得する簡単な方法を必要とする私たち（そして私たちの多くがいるのではないかと思う）にとって、ドキュメントデータベース（CouchDBなど）は天の恵みです。