1

ユーザーの「カタログ」を表示する REST API があります。カタログは、全体的なカタログ メタデータ (残りの金額など) を伴う製品のリストです。

このメタデータをカタログ応答に追加しようとしている段階ですが、データベースの設計に行き詰まりました。バッキング ストアは Amazon の DynamoDB であり、これは単なるキー値ストアです。特に、主キー (「ハッシュ」) や副キー (「範囲」) などをサポートしています。

現在、データベース エントリは次のようになっています。

{ customerId: "xxx", productId: "yyyy", productPrice: "zzz" }

これらを多かれ少なかれ直接カタログ エントリに変換できます。

{ products: [{ id: "yyyy", price: "zzz" }] }

しかし、次のようなメタデータを含む応答が必要です

{ metadata: { moneyLeft: 5 }, products: [{ id: "yyyy", price: "zzz" }] }

問題は、データベースにメタデータをどのように保存するかです。

アプローチ #1: データベースを分離する

すべてのメタデータ プロパティのプライマリ キーcustomerIdと列を使用して、個別のメタデータ テーブルを作成します。次に、両方のテーブル (DynamoDB への 2 つの HTTP リクエスト) に対してクエリを実行し、結果をまとめます。

アプローチ #2: クエリ指向

現在のテーブルを再利用して、このカタログ表示クエリ用に特別に設計します。次のような2種類の行があります

{ customerId: "xxx", productId: "yyyy", productPrice: "zzz", type: "product" }
{ customerId: "xxx", moneyLeft: 5, type: "metadata" }

（ただし、もう少し堅牢です）。次に、 を使用してテーブルからすべての行を選択するクエリを実行しcustomerId = xxx、サーバー コードでプロパティをオンにして目的の応答に変換しtypeます。

アプローチ 1 はまだリレーショナル DB の考え方にとらわれているようで、2 つの DB 呼び出し (= HTTP 要求) が必要になるため、私はアプローチ 2 に傾いています。しかし、それはとても奇妙で、それが良い考えかどうかはわかりません。たぶん、3番目のアプローチがありますか？本当の答えは「ドキュメント データベースを使用する必要がある」ということだと思いますが、この時点で、私たちは DynamoDB にかなりコミットしています ---。

4

1 に答える 1

0

テーブルのレンジキーは？ハッシュキーはcustomerIdだと思います...
全体的に、NoSQLソリューションについて考えると、「何をクエリするのか」と考えていることに気づき
ます。クエリが常に「customerId = XXXのすべてのアイテムをクエリする」である場合、それはそこに別の「メタデータ」アイテムを入れるのは悪い設計です。
より堅牢で無駄の多いアプローチは、メタデータをすべてのアイテムに連結することですが、更新に関してはそれ自体に欠点があります。(どちらもお勧めしません)
リレーショナルアプローチのように聞こえても、あなたのシナリオでは別のテーブルに固執すると思います。
さらに、データベースを部分的に理解することで、ユーザーのカタログを実際にクエリせずに、ユーザーのメタデータをクエリすることは理にかなっていると思います。

于 2012-06-25T08:20:40.913 に答える