0

私が知っているスキーマレスのプロジェクトにCouchbase Liteデータベースを使用しています。これで問題が解決するので非常に満足していますが、NoSQL（ドキュメントデータベース）の主キー制約に関連する1つの疑問が生じます。

すべてのスキーマ データベースがテーブルで表されることは周知のとおりであり、これらのテーブルにはプライマリ/フォージン キーがある場合とない場合があります。たとえば、usn(大学の座席番号) という主キーを持つ Student というテーブルがあり、その他の属性 (名、姓、住所、連絡先番号など) があるとします。

私たち | ファーストネーム | 姓 | 住所 | 連絡先番号

2BA11CS409 | abc | mnq | バンガロール | 1234567890

2BA11CS410 | xyz | PQR | ムンバイ | ムンバイ 1234567809

ここで、2BS11CS409 値をもう一度追加しようとすると、主キー制約違反 (重複キーを追加できない) というエラーが表示されます。

しかし、文書データベースの場合、文書内の一意の値をどのように識別し、

docID:123456789zxcv

{
usn : 2BA11CS409,
firstname : abc,
.......
....... etc
}

各ドキュメントには一意の ID が 1 つあり、そのキーはデータベースで検索するためにインデックス化されていることはわかっていますが、上記と同じ値を持つ別のドキュメントを作成すると、

docID:zxcv123456789
{
usn : 2BA11CS409,
firstname : abc,
last
....... etc
}

usn を使用して 1 つのデータベースにアクセスしようとすると、1 つのドキュメントだけが返されますが、2 つのドキュメントが返されますが、それらは同一または異なる可能性があります。

リレーショナル データベースに存在するドキュメント データベースの主キー/一意キーの種類の概念を知る必要があります。または、いくつかの記事にリダイレクトできます

ありがとうございました。

4

1 に答える 1

0

まあ、スキーマまたはスキーマなしの一意のキー制約は常にインデックスを使用します。ほとんどの RDB の利点は、このサービスを提供することです。基本的に、インデックスを表す 2 番目のコレクションがあります。usn標準コレクションに挿入するたびに、通常のコレクションにドキュメントを挿入しない場合は、挿入するドキュメントが存在するかどうかを最初にインデックスで確認します。次に、ドキュメントをインデックスにdocId=usn挿入します。必要に応じて、通常のコレクションに挿入したドキュメントの docID への参照を挿入できます。

于 2015-07-21T06:09:17.670 に答える