dynamodb 構造の作成中に発生した大きな間違いに気付きました。11 の表を作成しましたが、そのうちの 1 つは主に参照される表であり、残りは補完的な表です。たとえば、「Names」という名前を（他の情報とともに）保持するテーブルと、「Names」テーブルに追加されたこれらすべての名前を保持する「NamesMappings」という別のテーブルがあるため、ユーザーが名前を追加するたびに「Names」テーブルに対して、彼は最初に「NamesMappings」に名前を入れようとし、成功した場合にのみ (したがって、この名前は存在しません)、「Names」テーブルに名前を追加できます。この手順は、名前が一意ではなく、「名前」テーブルの主キーではない場合に役立ちます。この手法を使用すると、「名前」内を検索する必要がありません。
まず、これが一般的なアプローチなのか、それとももっと良いアプローチがあるのかお聞きしたいと思います。
次に、この設計では、すぐに 11 個のテーブルに到達し、それぞれに 5 つのプロビジョニングされた読み取りおよび書き込み容量があり、無料利用枠の下で全体で 55 個のプロビジョニングされた読み取りおよび書き込み容量につながることがわかりました。テーブルの数が増え、プロビジョニングされたキャパシティーをデフォルトのままにしておくと (読み取り/書き込みキャパシティーは両方とも 5)、プロビジョニングされたキャパシティーがますます増えるためです。
では、この理解から私の結論はどうあるべきでしょうか? テーブル内でスキャンとクエリを実行するのにより多くの労力がかかる場合でも、テーブルの数を減らそうとする必要がありますか? または、私と同じようにテーブルを分割する必要がありますが、アイテムが別のテーブルに存在するかどうかを示すためだけに使用されるこれらのマッピング テーブルの容量を減らしますか?