Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Entités de données gérées dans AWS App Studio

Généralement, vous configurez une entité dans App Studio avec une connexion à une table de base de données externe, et vous devez créer et mapper chaque champ d'entité avec une colonne dans la table de base de données connectée. Lorsque vous modifiez le modèle de données, la table de base de données externe et l'entité doivent être mises à jour, et les champs modifiés doivent être remappés. Bien que cette méthode soit flexible et permette l'utilisation de différents types de sources de données, elle nécessite une planification initiale plus poussée et une maintenance continue.

Une entité gérée est un type d'entité pour laquelle App Studio gère pour vous l'intégralité du processus de stockage et de configuration des données. Lorsque vous créez une entité gérée, une table DynamoDB correspondante est créée dans le compte associé AWS . Cela garantit une gestion des données sécurisée et transparente au sein de AWS. Dans le cas d'une entité gérée, vous configurez le schéma de l'entité dans App Studio, et la table DynamoDB correspondante est également automatiquement mise à jour.

Utilisation d'entités gérées dans plusieurs applications

Une fois que vous avez créé une entité gérée dans une application App Studio, cette entité peut être utilisée dans d'autres applications App Studio. Cela est utile pour configurer le stockage des données pour les applications ayant des modèles de données et des schémas identiques en fournissant une ressource sous-jacente unique à gérer.

Lorsque vous utilisez une entité gérée dans plusieurs applications, toutes les mises à jour du schéma de la table DynamoDB correspondante doivent être effectuées à l'aide de l'application d'origine dans laquelle l'entité gérée a été créée. Toute modification du schéma apportée à l'entité dans d'autres applications ne mettra pas à jour la table DynamoDB correspondante.

Limites relatives aux entités gérées

Restrictions relatives à la mise à jour de la clé primaire  : vous ne pouvez pas modifier le nom ou le type de clé primaire de l'entité une fois celle-ci créée, car il s'agit d'une modification destructive dans DynamoDB qui entraînerait la perte de données existantes.

Renommer des colonnes  : lorsque vous renommez une colonne dans DynamoDB, vous créez en fait une nouvelle colonne tout en conservant les données d'origine dans la colonne d'origine. Les données d'origine ne sont pas automatiquement copiées dans la nouvelle colonne ni supprimées de la colonne d'origine. Vous pouvez renommer les champs d'entités gérées, appelés nom du système, mais vous perdrez l'accès à la colonne d'origine et à ses données. Il n'y a aucune restriction quant au changement de nom d'affichage.

Modification du type de données  : Bien que DynamoDB offre la flexibilité nécessaire pour modifier les types de données des colonnes après la création de la table, ces modifications peuvent avoir de graves répercussions sur les données existantes ainsi que sur la logique et la précision des requêtes. Les modifications de type de données nécessitent la transformation de toutes les données existantes pour les rendre conformes au nouveau format, qui est complexe pour les tableaux actifs de grande taille. En outre, les actions relatives aux données peuvent produire des résultats inattendus tant que la migration des données n'est pas terminée. Vous pouvez changer le type de données des champs, mais les données existantes ne seront pas migrées vers le nouveau type de données.

Colonne de tri  : DynamoDB permet de récupérer des données triées à l'aide de touches de tri. Les clés de tri doivent être définies comme faisant partie des clés primaires composites avec la clé de partition. Les limites incluent la clé de tri obligatoire, le tri confiné à une partition et l'absence de tri global entre les partitions. Une modélisation minutieuse des données des clés de tri est requise pour éviter les partitions actives. Nous ne prendrons pas en charge le jalon Sorting for Preview.

Jointures  : les jointures ne sont pas prises en charge dans DynamoDB. Les tables sont dénormalisées de par leur conception afin d'éviter des opérations de jointure coûteuses. Pour modéliser des relations un-à-plusieurs, la table enfant contient un attribut faisant référence à la clé primaire de la table parent. Multi-table les requêtes de données impliquent la recherche d'éléments dans la table parent pour récupérer des détails. Nous ne prendrons pas en charge les jointures natives pour les entités gérées dans le cadre de l'étape de la version préliminaire. Pour contourner ce problème, nous allons introduire une étape d'automatisation qui permet d'effectuer une fusion de données de 2 entités. Ce sera très similaire à une recherche à un niveau. Nous ne prendrons pas en charge le jalon Sorting for Preview.

Étape d'environnement  : nous autoriserons la publication à des fins de test, mais nous utiliserons le même magasin géré dans les deux environnements