As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Entidades de dados gerenciadas em AWS Estúdio de aplicativos

Normalmente, você configura uma entidade no App Studio com uma conexão com uma tabela de banco de dados externa e precisa criar e mapear cada campo de entidade com uma coluna na tabela do banco de dados conectado. Quando você faz uma alteração no modelo de dados, a tabela do banco de dados externo e a entidade devem ser atualizadas e os campos alterados devem ser remapeados. Embora esse método seja flexível e permita o uso de diferentes tipos de fontes de dados, ele exige mais planejamento antecipado e manutenção contínua.

Uma entidade gerenciada é um tipo de entidade para a qual o App Studio gerencia todo o processo de configuração e armazenamento de dados para você. Quando você cria uma entidade gerenciada, uma tabela correspondente do DynamoDB é criada na conta associada AWS . Isso garante um gerenciamento de dados seguro e transparente no interior AWS. Com uma entidade gerenciada, você configura o esquema da entidade no App Studio, e a tabela correspondente do DynamoDB também é atualizada automaticamente.

Usando entidades gerenciadas em vários aplicativos

Depois de criar uma entidade gerenciada em um aplicativo do App Studio, essa entidade pode ser usada em outros aplicativos do App Studio. Isso é útil para configurar o armazenamento de dados para aplicativos com modelos e esquemas de dados idênticos, fornecendo um único recurso subjacente para manutenção.

Ao usar uma entidade gerenciada em vários aplicativos, todas as atualizações do esquema na tabela correspondente do DynamoDB devem ser feitas usando o aplicativo original no qual a entidade gerenciada foi criada. Qualquer alteração de esquema feita na entidade em outros aplicativos não atualizará a tabela correspondente do DynamoDB.

Limitações de entidades gerenciadas

Restrições de atualização da chave primária: você não pode alterar o nome ou o tipo da chave primária da entidade após sua criação, pois essa é uma alteração destrutiva no DynamoDB e resultaria na perda dos dados existentes.

Renomeando colunas: ao renomear uma coluna no DynamoDB, você realmente cria uma nova coluna enquanto a coluna original permanece com os dados originais. Os dados originais não são copiados automaticamente para a nova coluna nem excluídos da coluna original. Você pode renomear campos de entidades gerenciadas, conhecidos como nome do sistema, mas perderá acesso à coluna original e seus dados. Não há restrição em renomear o nome de exibição.

Alteração do tipo de dados: embora o DynamoDB permita flexibilidade para modificar os tipos de dados da coluna após a criação da tabela, essas alterações podem afetar gravemente os dados existentes, bem como a lógica e a precisão da consulta. As mudanças nos tipos de dados exigem a transformação de todos os dados existentes para que estejam em conformidade com o novo formato, que é complexo para tabelas ativas grandes. Além disso, as ações de dados podem retornar resultados inesperados até que a migração de dados seja concluída. Você pode alternar os tipos de dados dos campos, mas os dados existentes não serão migrados para o novo tipo de dados.

Coluna de classificação: o DynamoDB permite a recuperação de dados classificados por meio de chaves de classificação. As chaves de classificação devem ser definidas como parte das chaves primárias compostas junto com a chave de partição. As limitações incluem chave de classificação obrigatória, classificação confinada em uma partição e nenhuma classificação global entre partições. É necessária uma modelagem cuidadosa dos dados das chaves de classificação para evitar partições ativas. Não daremos suporte ao marco Sorting for Preview.

Junções: as uniões não são suportadas no DynamoDB. As tabelas são desnormalizadas por design para evitar operações de junção caras. Para modelar relacionamentos de um para muitos, a tabela secundária contém um atributo que faz referência à chave primária da tabela principal. Multi-table as consultas de dados envolvem a busca de itens da tabela principal para recuperar detalhes. Não daremos suporte a uniões nativas para entidades gerenciadas como parte do marco do Preview. Como solução alternativa, apresentaremos uma etapa de automação que pode realizar uma mesclagem de dados de duas entidades. Isso será muito semelhante a uma pesquisa de um nível. Não daremos suporte ao marco Sorting for Preview.

Env Stage: permitiremos que a publicação teste, mas use o mesmo armazenamento gerenciado em ambos os ambientes