翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
通常、外部データベーステーブルへの接続を使用して App Studio でエンティティを設定し、各エンティティフィールドを作成して、接続されたデータベーステーブルの列にマッピングする必要があります。データモデルを変更するときは、外部データベーステーブルとエンティティの両方を更新し、変更されたフィールドを再マッピングする必要があります。この方法は柔軟で、さまざまなタイプのデータソースを使用できますが、事前計画と継続的なメンテナンスが必要です。
マネージドエンティティは、App Studio がデータストレージと設定プロセス全体を管理するエンティティのタイプです。マネージドエンティティを作成すると、対応する DynamoDB テーブルが関連付けられた AWS アカウントに作成されます。これにより、 内の安全で透過的なデータ管理が保証されます AWS。マネージドエンティティでは、App Studio でエンティティのスキーマを設定すると、対応する DynamoDB テーブルも自動的に更新されます。
複数のアプリケーションでのマネージドエンティティの使用
App Studio アプリでマネージドエンティティを作成すると、そのエンティティを他の App Studio アプリで使用できます。これは、維持する単一の基盤となるリソースを提供することで、同じデータモデルとスキーマを持つアプリケーションのデータストレージを設定するのに役立ちます。
複数のアプリケーションでマネージドエンティティを使用する場合、対応する DynamoDB テーブルに対するすべてのスキーマ更新は、マネージドエンティティが作成された元のアプリケーションを使用して行う必要があります。他のアプリケーションのエンティティに対してスキーマを変更しても、対応する DynamoDB テーブルは更新されません。
マネージドエンティティの制限
プライマリキーの更新の制限: エンティティのプライマリキー名またはタイプは、DynamoDB の破壊的な変更であり、既存のデータが失われる可能性があるため、作成後に変更することはできません。
列の名前変更: DynamoDB で列の名前を変更すると、元の列が元のデータのままである間に、実際に新しい列が作成されます。元のデータは、新しい列に自動的にコピーされたり、元の列から削除されたりすることはありません。システム名と呼ばれるマネージドエンティティフィールドの名前は変更できますが、元の列とそのデータにアクセスできなくなります。表示名の変更に制限はありません。
データ型の変更: DynamoDB では、テーブルの作成後に列データ型を柔軟に変更できますが、このような変更が既存のデータやクエリロジック、精度に重大な影響を与える可能性があります。データ型の変更には、既存のすべてのデータを変換して新しい形式に準拠する必要があります。これは、大規模でアクティブなテーブルでは複雑です。さらに、データアクションは、データ移行が完了するまで予期しない結果を返す場合があります。フィールドのデータ型を切り替えることはできますが、既存のデータは新しいデータ型に移行されません。
列のソート: DynamoDB はソートキーによるソートされたデータの取得を有効にします。ソートキーは、パーティションキーとともに複合プライマリキーの一部として定義する必要があります。制限事項には、必須のソートキー、1 つのパーティション内に限定されたソート、パーティション間のグローバルソートはありません。ホットパーティションを回避するには、ソートキーの慎重なデータモデリングが必要です。Sorting for Preview のマイルストーンはサポートされません。
結合: 結合は DynamoDB ではサポートされていません。テーブルは、高価な結合操作を避けるために、設計によって非正規化されます。one-to-many関係をモデル化するために、子テーブルには親テーブルのプライマリキーを参照する属性が含まれています。マルチテーブルデータクエリでは、親テーブルから項目を検索して詳細を取得します。プレビューマイルストーンの一環として、マネージドエンティティのネイティブ結合はサポートされません。回避策として、2 つのエンティティのデータマージを実行できる自動化ステップを紹介します。これは、1 レベルのルックアップと非常によく似ています。Sorting for Preview のマイルストーンはサポートされません。
Env ステージ: 公開によるテストは許可されますが、両方の環境で同じマネージドストアを使用します。
