NoSQL データベース、OODB、またはそれらに存在するその他の頭字語のベスト プラクティスは何ですか?
たとえば、クライアントであるアプリケーションが DB ドキュメント (couchDB/mongoDB 用語で) をどのように解釈するかを決定するために、フィールド「タイプ」が使用されているのをよく見てきました。
該当する場合は、PHP を参照言語として使用してください。読む: 厳密には DB 構造だけでなく、そのようなデータをクライアント側でどのように処理するのが最善なのかにも興味があります。これは実質的に、SQL DB の「ORM」のようなパターン (アクティブ レコード、データ マッパーなど) も探していることを意味します。
このような DB と PHP 5.3 の新機能がどのように連携するのが最適かについて、遠慮なく意見を述べてください。
現在、NoSQLデータストアの全体的な考え方とドキュメントデータベースの概念は非常に新しく、リレーショナルストレージを推進する確立された考え方とは異なるため、現在のところベストプラクティスはほとんどありません。
この時点で、たとえばCouchDB（またはその他のドキュメントデータベース）内にデータを格納するためのルールは、リレーショナルデータベースのルールとはかなり異なることがわかっています。たとえば、正規化と3NFの目標化は、努力すべきものではないというのは事実です。一般的な例の1つは、単純なブログの例です。
リレーショナルストアには、「投稿」、「コメント」、「作成者」のそれぞれのテーブルがあります。各作成者には多くの投稿があり、各投稿には多くのコメントがあります。これは十分に機能するモデルであり、任意のリレーショナルDBに適切にマッピングされます。ただし、同じデータをdocDB内に格納することは、おそらくかなり異なります。おそらく、投稿ドキュメントのコレクションのようなものがあり、それぞれに独自の作成者とコメントのコレクションが埋め込まれています。もちろん、それが唯一の方法ではなく、多少の妥協点です（現在は単一の投稿のクエリは高速です。1回の操作ですべてを取り戻すことができます）が、作成者と投稿の関係を維持する方法はありません（すべてが投稿ドキュメントの一部になるため）。
私も「type」属性を使用する例を見てきました（CouchDBの例）。確かに、それは実行可能なアプローチのように聞こえます。最高ですか？手がかりがありません。確かに、MongoDBでは、データベース内で個別のコレクションを使用するため、type属性はまったく意味がありません。CouchDBでは...おそらくそれが最善です。他の選択肢は？ドキュメントの種類ごとに個別のデータベース？これは少しループしているように見えるので、私は自分で「タイプ」ソリューションに傾倒します。しかし、それは私だけです。おそらくもっと良いものがあります。
私はここでかなり歩き回って、ほとんど何も言わなかったことに気づきました。おそらくあなたがまだ知らなかったことは何もありません。私のポイントはこれですが、私たちが持っているツールと使用しているデータを実験するのは私たちの責任だと思います。時間の経過とともに、優れたアイデアが広まり、ベストプラクティスになります。ゲームの早い段階で質問していると思います。
「NoSQL」は、特定の構造に従うようにアプリを構築することではなく、アプリケーションの要件に従うようにデータストアを構築することに関するものである必要があります。これは、従来のSQL アプローチに似ています。
「理由だけで」リレーショナル データベースを放棄しないでください。アプリが本当に必要な場合にのみ実行してください。