問題タブ [document-oriented-db]

私が理解しているように、ドキュメント指向のデータベースには構造化されていない情報を入力できます。次のようなドキュメントを想像してみましょう。

その後、新しいバージョンで、この構造は次のようにリファクタリングされます。

ドキュメント指向データベースでこれをどのように行いますか? データベース内のすべてのエントリを変更するマージ スクリプトを準備する必要がありますか? または、構造の変更を処理するためのより良い方法はありますか?

最近、私はMongoDBを少し使っていますが、本当に気に入っていると言わざるを得ません。しかし、それは完全に異なるタイプのデータベースであり、私は使用されています。特定のタイプのデータには間違いなく優れていることに気づきましたが、高度に正規化されたデータベースの場合は、最良の選択ではない可能性があります。

しかし、私には、それはあなたが持っている可能性のあるほぼすべてのリレーショナルデータベースの代わりになり、ほとんどの場合、パフォーマンスが向上するように見えます。これは気が遠くなるようなことです。これは私にいくつかの質問をするように導きます：

1. ドキュメント指向データベースは、次世代データベースとして開発されており、基本的にリレーショナルデータベースに完全に取って代わっていますか？
2. ドキュメント指向データベースとリレーショナルデータベースの両方を、どちらか一方に適したさまざまなデータに並べて使用する方がプロジェクトがうまくいく可能性はありますか？
3. ドキュメント指向データベースがリレーショナルデータベースを置き換えることを意図していない場合、リレーショナルデータベースで絶対的に優れている（またはその逆の）データベース構造の例を誰かが持っていますか？

ドキュメント指向のデータベースを設計する際のガイドラインがあるかどうか疑問に思っています。特にCouchDbについて話しています。

スキーマレスであることは私たちが望む形をとることができることを私は知っていますが、ベストプラクティスはありますか？

前もって感謝します！= D

mongo db を使用してブログ投稿ストレージを実装しようとしています。

2 つのドメイン エンティティがあります。

「ブログ投稿」と「作成者」

現在、AuthorId プロパティをブログ投稿エンティティに追加しました。それはオブジェクト間の関係を保存するための正しいアプローチですか?

ご挨拶、

私はphpを使用して個人のWebサイトを構築しています。私の標準的なアプローチは、MySQLをデータベースバックエンドとして使用することです。私はドキュメント指向データベースについて多くのことを聞いてきましたが、これら（couchDB、mongoDB）が私にとってより良いオプションであるかどうか疑問に思っています。

私の個人ホームページのようなトラフィックの少ないサイトでは、別のDBを実行しても大幅な改善は見られないことは理解していますが、「ささいなこと」には感謝しています。

データベースは主に、コメントやブログ投稿などのテキストデータを保持します。それ以外にいくつかの画像を保存します。

要約すると、特定のDBバックエンド、特に新しいドキュメント指向のバックエンドを使用することについて、賛否両論、またはその他の批評を誰かに教えてもらえますか？

ありがとう。

リレーショナル データベースにデータを格納するという観点から考えると、複雑さがかなり明白な cv バンクを作成しようとしています。この場合、couchdb の方が理にかなっているでしょうか?

私が保管するものの例

ユーザーの教育、資格、雇用、賞、言語、スキル、ライセンス、協会との 1 対多の関係

私はいくつかのドキュメント指向ストアの成熟度に関する調査を行っています。これには、運用環境でデータベースを使用するアプリケーションと Web サイトの概要が含まれます。CouchDB と MongoDB については、次のようなリストとケース スタディがいくつかあります。

• 野生の CouchDB
• MongoDB 本番デプロイメント

本番環境で RavenDBを使用するアプリケーションや Web サイトを見つけるのに苦労しています。RavenDB で実行されている (よく知られている) サイトの例や、これを直接経験した人はいますか?

MongoDB、CouchDB、SimpleDB などのスキーマレス (多くの場合、分散型) データベース システムについての話をよく耳にします。

それらが何らかの目的で価値があることは理解できますが、ほとんどのアプリケーションでは、特定のタイプの特定の数のフィールドを持つオブジェクトを永続化しようとしており、リレーショナル モデルで自動的に考えます。私は常に、一意の整数 ID、null/not null フィールド、SQL データ型、選択クエリを使用してセットを検索する行の観点から考えています。

私はこれらの新しいシステムの分散型の性質と簡単な JSON/RESTful インターフェイスに惹かれていますが、緩く型付けされたキー/値ハッシュが開発にどのように役立つかはわかりません。型が緩く、スキーマのないシステムが、クリーンなデータ セットを維持するのに適しているのはなぜでしょうか? たとえば、日付がない可能性があるときに、x と y の間の日付を持つすべてのアイテムを見つけるにはどうすればよいですか? 結合の概念はありますか?

多くのシステムには独自の違いと長所があることは理解していますが、パラダイムの違いについて疑問に思っています。これは自由回答形式の質問だと思いますが、おそらくコミュニティの回答と、これらのシステムの利点を個人的に見たコミュニティの方法は、私や他の人がいつこれらの (確かにもっとヒップな) システムを使用したいのかを理解するのに役立つでしょう。従来の RDBMS。

重複の可能性:
スキーマレス データベース システムの魅力は何ですか?

リレーショナル データベースに対するドキュメント指向データベースの利点は何ですか? ドキュメント指向データベースはどこで使用すればよいですか?

はじめに、具体的な問題はないと思いますが、これらを管理するシステムがないのは奇妙に感じます。

現在、ディレクトリの階層に大量の XML ファイルがあります。これらのフォルダーの周りにドキュメント指向の DB を使用すると便利だと思います。検索目的には非常に役立つ可能性がありますが、現在、検索の必要はありません。

現在、データベースを使用する実際のビジネス上の理由を考えるのに苦労しています。「システムを高速化する」機会を提供してくれるかもしれませんが、スケーラビリティが問題になるとは思えません。

他に考慮していないことはありますか？