これまで見てきたことは、ブロブを格納するための単一のテーブルとそれに適用されるタグのための 2 番目のテーブルよりも興味深いものではないことを示唆しているため、何かが欠けているに違いありません。
確かに、設計パターンからある程度の利点が得られますが、SQL Server、Oracle、Postgres などの従来のデータベースを使用して構築するのではなく、「ドキュメント指向の DBMS」を使用する必要があるのはなぜでしょうか?
3 に答える
4
CouchDB に関するフロスの毎週のエピソードを楽しく聞きました。そこにはたくさんの推論とアイデアがあります。
聞く前に、このトピックについて読んだもののほとんどは、(私にとって) あまり洞察を引き起こしませんでした。ドキュメント指向 DB を使用する理由と場所について人々が話し、推論するのを聞くことは、概念、推論、長所と短所を実際に理解するのに大いに役立ちました。これで、すべての記事とステートメント (IMHO) が突然、より意味のあるものになりました。
あなたのマイレージは異なるかもしれませんが、これは私を大いに助けました.
于 2009-11-15T08:55:37.587 に答える
0
(Documentum のような ECM 製品ではなく) Couch DB や Tokyo Cabinet などの製品を意味していると思います。多くの開発者にとっての魅力は親しみやすさだと思います。
まず、概念モデル (ほとんどの場合) は、構成ファイルのようなキーと値のペアです。ほとんどのフレームワークは多くの構成のラングリングを必要とするように見えるため、フロントエンド/中間層の開発者はその作業方法に慣れています。第二に、これらのツールは、Java、Python などの開発者向けの言語でインターフェースを提供します。
一方、従来の RDBMS 製品では、リレーショナルという別の方法で考える必要があります。また、奇妙な言語である SQL だけでなく、手続き型ではなくセットベースの新しいプログラミング方法を学ぶ必要があります。データベースのストアド プロシージャではなく中間層にビジネス ロジックを配置するという議論を繰り返してみると、その多くは No SQL にも当てはまります。
于 2009-11-15T08:46:42.873 に答える