Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Entidades de datos administradas en AWS App Studio

Normalmente, configuras una entidad en App Studio con una conexión a una tabla de base de datos externa y debes crear y asignar cada campo de entidad a una columna de la tabla de base de datos conectada. Al realizar un cambio en el modelo de datos, se deben actualizar tanto la tabla de la base de datos externa como la entidad, y los campos modificados se deben volver a asignar. Si bien este método es flexible y permite el uso de diferentes tipos de fuentes de datos, requiere una mayor planificación inicial y un mantenimiento continuo.

Una entidad gestionada es un tipo de entidad en la que App Studio gestiona todo el proceso de almacenamiento y configuración de datos por ti. Al crear una entidad gestionada, se crea la tabla de DynamoDB correspondiente en la cuenta asociada AWS . Esto garantiza una gestión de datos interna segura y transparente. AWS Con una entidad gestionada, se configura el esquema de la entidad en App Studio y la tabla de DynamoDB correspondiente también se actualiza automáticamente.

Uso de entidades administradas en varias aplicaciones

Una vez que hayas creado una entidad gestionada en una aplicación de App Studio, esa entidad se puede usar en otras aplicaciones de App Studio. Esto resulta útil para configurar el almacenamiento de datos para aplicaciones con esquemas y modelos de datos idénticos, ya que proporciona un único recurso subyacente que mantener.

Cuando se utiliza una entidad gestionada en varias aplicaciones, todas las actualizaciones del esquema de la tabla de DynamoDB correspondiente deben realizarse con la aplicación original en la que se creó la entidad gestionada. Los cambios de esquema realizados en la entidad en otras aplicaciones no actualizarán la tabla de DynamoDB correspondiente.

Limitaciones de las entidades administradas

Restricciones de actualización de la clave principal: no puede cambiar el nombre o el tipo de clave principal de la entidad una vez creada, ya que se trata de un cambio destructivo en DynamoDB y podría provocar la pérdida de los datos existentes.

Cambiar el nombre de las columnas: al cambiar el nombre de una columna en DynamoDB, en realidad se crea una nueva columna mientras la columna original permanece con los datos originales. Los datos originales no se copian automáticamente en la nueva columna ni se eliminan de la columna original. Puede cambiar el nombre de los campos de la entidad administrada, conocidos como nombre del sistema, pero perderá el acceso a la columna original y a sus datos. No hay ninguna restricción a la hora de cambiar el nombre para mostrar.

Cambiar el tipo de datos: aunque DynamoDB ofrece flexibilidad para modificar los tipos de datos de las columnas tras la creación de la tabla, estos cambios pueden afectar gravemente a los datos existentes, así como a la lógica y precisión de las consultas. Los cambios en los tipos de datos requieren la transformación de todos los datos existentes para adaptarlos al nuevo formato, que es complejo para tablas grandes y activas. Además, las acciones de datos pueden arrojar resultados inesperados hasta que se complete la migración de datos. Puede cambiar los tipos de datos de los campos, pero los datos existentes no se migrarán al nuevo tipo de datos.

Columna de clasificación: DynamoDB permite la recuperación de datos ordenados mediante claves de clasificación. Las claves de clasificación deben definirse como parte de las claves principales compuestas junto con la clave de partición. Las limitaciones incluyen la clave de clasificación obligatoria, la clasificación limitada a una partición y la falta de clasificación global entre las particiones. Es necesario modelar cuidadosamente los datos de las claves de clasificación para evitar que las particiones se quemen. No apoyaremos el hito de Sorting for Preview.

Uniones: DynamoDB no admite uniones. Las tablas están desnormalizadas por diseño para evitar costosas operaciones de unión. Para modelar relaciones de uno a varios, la tabla secundaria contiene un atributo que hace referencia a la clave principal de la tabla principal. Multi-table Las consultas de datos implican buscar elementos de la tabla principal para recuperar detalles. Como parte del objetivo de la versión preliminar, no admitiremos las uniones nativas para las entidades gestionadas. Como solución alternativa, introduciremos un paso de automatización que permite combinar datos de dos entidades. Será muy similar a una búsqueda de un solo nivel. No apoyaremos el hito Sorting for Preview.

Env Stage: Permitiremos la publicación para realizar pruebas, pero utilizaremos la misma tienda gestionada en ambos entornos