0

アプリケーションでさまざまなエンティティ (ユーザー、プロジェクト、フォルダー、ドキュメントなど) へのカスタム属性をサポートする必要があるアプリケーションを開発したいと考えています。

私はグーグルで検索しましたが、No-SQLデータベースが私たちの要件に適しているように見えます. 制限はありますか？RDBMS の代わりに No-SQL を使用することの長所と短所は何ですか?

多くの NO-SQL データベースが利用可能です - http://nosql-database.org/ ? しかし、私たちは No SQL データベースを使用した経験がありません。これらの NO-SQL データベースを比較する良い記事が見つかりません。カスタム属性機能を実現するために使用できる No-SQL データ ストアについて何か提案はありますか?

4

3 に答える 3

1

No-sql データベースの大きな利点の 1 つは、その自由なスタイルです。実際のデータを挿入する前に、「ユーザー、プロジェクト、フォルダー」などの列を指定する必要はありません。列はいつでも追加できます。

RDBMS では、テーブル スキーマは厳密に定義されており、実行時に変更することはできません。

もう 1 つの利点は、クエリでのパフォーマンスです。「Michael」などのユーザーのすべてのレコードを照会すると、非常に効率的です。これは、データが google によって命名された Big Table の原則に従って保存されるためです。

于 2016-01-11T15:45:49.390 に答える
0

質問を解決するには、2つの方法があります。Cassandraなどの列データベース。または、リレーショナルの名前と値のペア（属性と値のペアとも呼ばれます）。

まず、Cassandraは構造化されたKey-Valueストアです。キーには、複数の変数の属性と値を含めることができます。値または列は、列ファミリーにグループ化されます。列ファミリーは、Cassandraデータベースが作成されるときに修正されます。ファミリは、論理データモデルのエンティティまたはリレーショナルのテーブルに類似しています。列はいつでもファミリに追加できます。これにより、列ファミリーのさまざまなインスタンスがさまざまな列を持つことができます。これが必要なことです。さらに、列は指定されたキーに割り当てられるため、キーが異なれば、特定のファミリの列の数も異なります。

名前と値のペアは、属性と値のペアとも呼ばれ、論理データモデリングおよびリレーショナルで作成できます。これは、3つの関連するエンティティまたはテーブルを使用して実行できます。

  • 列ファミリーに類似したベースエンティティ（顧客など）。
  • 属性とその特性（純資産額など）を説明する「タイプ」エンティティ。
  • 「値」エンティティ。ベースエンティティのインスタンスに属性を割り当て、それに値を割り当てます。

「タイプ」エンティティは、タイプコードによって識別され、説明やその他のドメイン特性を含む単なるコードテーブルです。ドメインとは、データタイプ、長さ、意味、および測定単位を指します。コンテキスト外（つまり、割り当てられていない）の属性を記述します。例としては、右寄せされた小数点以下2桁の8桁の純資産額があり、その説明は「流動性と非流動性の金額を含む顧客の総財務価値を表す値」です。

「value」エンティティは、顧客IDと属性タイプコードによって識別される連想エンティティまたはテーブルであり、純資産額タイプに顧客を割り当て、「$2,000,000」などの値を与えるvalue属性を持っています。

ただし、リレーショナルの名前と値のペアでは、SQLでクエリを実行するのがやや難しく、通常はうまく機能しません。これは、「タイプ」エンティティと「値」エンティティを1つに非正規化することで対処できます。3つのテーブルを使用する代わりに、2つ（1対多）を使用します。実際、それは本質的にカサンドラがそれを行う方法です。列ファミリーは、完全にフラット化された属性と値のペアです。

これがお役に立てば幸いです。NOSQLを使用する場合は、Cassandraのようなものを使用します。リレーショナルを使用する場合は、タイプと値を非正規化します（つまり、1つにまとめます）。リレーショナルの利点は、すでに持っていることです。カサンドラの欠点は、あなたがそれを学ばなければならないということですが、それはあなたが望むことをするために作られています。

于 2012-08-27T01:45:58.603 に答える
0

モデルをJSONにカプセル化できれば、Couchbaseはあなたにとって素晴らしい答えになるでしょう。オブジェクトのプロパティはいくつでも持つことができます:

product::001 { "名前": "ハードドライブ", "ブランド": "東芝", ... ... }

RDBMS から Couchbase に移行するいくつかの単純なパターンを学ぶには、http://www.couchbase.com/webinarsでウェビナーをチェックするか、http: //CouchbaseModels.comでいくつかの単純な設計パターンをチェックしてください(例は Ruby で書かれています)。

Couchbase の真の利点は、スキーマの柔軟性、コモディティ ハードウェアでの水平方向のスケーラビリティ、および速度です。基本を学んだ後は、移行の必要がほとんどなく、アジャイル プロセスにより適しています。企業組織では、すべての列の変更にビジネス プロセスと DBA の承認が必要になるため、非常に効果的です。Couchbase スキーマの柔軟性は、これらの問題の多くを回避します。

于 2012-08-27T02:50:11.713 に答える