[解決済み] 非リレーショナルデータベース設計【終了しました

質問

で使用したことのあるデザイン戦略についてお聞きしたいのですが。 非リレーショナルなnosqlデータベース - つまり、伝統的なリレーショナルデザインやSQLを使用しないデータストア（Hypertable、CouchDB、SimpleDB、Google App Engine datastore、Voldemort、Cassandra、SQL Data Servicesなど）の（主に新しい）クラスのことです。これらはしばしば「キー/バリュー ストア」とも呼ばれ、基本的には巨大な分散永続ハッシュ テーブルのように動作します。

具体的には、次のような違いについて学びたいと思います。 概念的なデータ設計 の違いについて知りたいのです。何が簡単で、何が難しいのか、何がまったくできないのか。

• 非リレーショナルな世界でよりよく機能する代替設計を考え出しましたか？

• 不可能と思われることに頭をぶつけたことがありますか？

• 何かデザインパターンを使って、一方から他方への変換など、ギャップを埋めたことがありますか？

• 現在、明示的なデータモデル (例: UML) をまったく使用していないのですか、それとも半構造化/文書指向のデータブロブを支持して、それらを完全に削除したのですか?

• リレーショナルインテグリティ、任意に複雑なトランザクションサポート、トリガーなど、RDBMS が提供する主要な追加サービスを逃していませんか?

私は SQL リレーショナル DB のバックグラウンドから来ましたので、正規化は私の血の中にあります。とはいえ、私はシンプルさとスケーリングのための非リレーショナル データベースの利点を理解しており、設計機能のより豊かな重複があるはずだと直感的に感じています。あなたは何をしましたか？

参考までに、同様のトピックについて StackOverflow のディスカッションがここにあります。

• 次世代データベース
• Google App Engine で動作するようにスキーマを変更する
• ドキュメント指向のデータベースの選択

どのように解決するのですか？

非リレーショナルDBMSはデータモデルが大きく異なるので、概念的なデータ設計も大きく異なることを考慮する必要があると思います。このスレッドでは 非リレーショナル データベースのデータ設計 の NOSQL Google グループ では、さまざまなパラダイムがこのように分類されています。

1. Bigtableライクなシステム（HBase, Hypertableなど)
2. Key-value store (Tokyo、Voldemort, など)
3. ドキュメントデータベース（CouchDB。 MongoDB、など)
4. グラフデータベース（AllegroGraph, Neo4j、Sesameなど)

私が主に取り組んでいるのは グラフデータベース の欠点に嫌気がさした私は、このパラダイムを使ったデータ設計のエレガンスに惹かれて、この世界に飛び込みました。 RDBMS . グラフ・データベースを使ったデータ設計の例をいくつか、この wikiページ というページがあり、そこに をモデル化する方法の例があります。 基本的な IMDB 映画、俳優、役柄のデータも

発表スライド(slideshare) グラフデータベースと大規模ナレッジマネジメントの未来 傍点 マルコ・ロドリゲス は、グラフデータベースを使用したデータ設計についても、非常に素晴らしい紹介をしています。

グラフデータベースの観点から、具体的な質問に答えています。