こんにちはiamはdynamodbの新機能であり、私の知る限り、非リレーショナルdbです。つまり、テーブルを結合できません。私の疑問は、テーブル構造をどのように設計するかです。次の例で明確にしてください。
次の表があります。1）ユーザー-user_id、ユーザー名、パスワード、電子メール、電話番号、役割2）役割-id、名前[つまり、管理者、スーパーバイザーなど]
a）私の最初の疑問は、user_idフィールドの自動インクリメントを設定するためのプロビジョニングがあるかどうかです。b）主キーをuser_idとして設定するこの正しい方法はありますか？c）これはdynamodbにユーザーロールを保存する正しい方法ですか？つまり、ロールテーブルにはIDとタイトルが含まれ、ロールIDをユーザーテーブルに保存しますか？e）各ユーザーと一緒に2つのテーブルデータを取得することは可能ですか？rails3とaws-sdkgemを使用しています
誰かが返信した場合、それは新しいdynamodbユーザーのように私にとって非常に役立ちます
通常、nosql スタイルのデータベースでは、自動インクリメント PK フィールドを使用するのではなく、一意の識別子を提供します。これは通常、GUID を各ユーザー レコードのキーにすることを意味します。
ユーザーの役割に関する限り、これを達成する方法は数多くあり、それぞれに利点と問題があります。
簡単な方法の 1 つは、「ロール」属性をユーザー テーブルに追加し、そのユーザーのロールごとに 1 つのエントリを作成することです。次に、ユーザーを取得すると、1 つのクエリですべてのロールを取得できます。DynamoDB では、属性が複数の値を持つことができるため、1 つの属性がロールごとに 1 つの値を持つことができます。
特定のロールのユーザーにクエリを実行できるようにする必要がある場合 (つまり、「スーパーバイザーであるすべてのユーザーを教えてください」)、DynamoDB でテーブル スキャンを実行することになりますが、これはコストのかかる操作になる可能性があります。ただし、ユーザー数がかなり少なく、この種のルックアップを実行する必要があまりない場合は、アプリケーションでこれでも問題ない可能性があります。
この高価なタイプのルックアップを頻繁に行う必要がある場合は、ロールごとに 1 つのレコードを持ち、ロール レコード内のユーザーの userIds を持つ "RolesWithUsers" のような新しいテーブルを作成する必要があります。ほとんどのアプリケーションでは、このようなことをしないことをお勧めします。これは、特定のユーザーが持つ役割という 1 つの事実を表す 2 つのテーブルがあるためです。そのため、削除または更新は毎回 2 か所で行う必要があります。不可能ではありませんが、アプリケーションが間違ったデータを取得しないようにするには、より多くの警戒とテストが必要です。このアプローチのもう 1 つの欠点は、情報を取得するために 2 つのクエリが必要になることです。これも、レコードの量によっては、テーブル スキャンよりもコストがかかる可能性があります。
この特定のユース ケースに適した別のオプションは、SimpleDb を使用することです。より優れたクエリ機能 (すべての属性がデフォルトでインデックス化されます) を備えており、この場合、多値属性としてロールを持つ単一のテーブルは、DynamoDB よりもはるかに優れたソリューションになります。
お役に立てれば！
同様の状況があり、リレーショナルと NoSQL (Dynamo) の 2 つの DB を使用するだけです。「ユーザー」オブジェクトの場合、ロール、プロジェクト、スキルなど、他のものに関連付けられているものはすべてリレーショナルになり、ユーザーに関するすべて (属性など) は Dynamo に入ります。ユーザーに新しい属性を追加する必要がある場合でも、NoSQL はそれらの属性を気にしないので問題ありません。経験則として、そのオブジェクト ページに何かが必要な場合 (つまり、他のオブジェクトと関連付ける必要がない場合) は、Dynamo を配置します。それ以外の場合は、リレーショナルになります。
NoSQL DB でテーブル スキャンを使用することは、小さなしきい値を超えた後でも実際にはオプションではありません (その時点までは、メモリ内 DB を使用できます)。