Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Entità di dati gestite in AWS App Studio

In genere, si configura un'entità in App Studio con una connessione a una tabella di database esterna e si deve creare e mappare ogni campo di entità con una colonna nella tabella del database connessa. Quando si apporta una modifica al modello di dati, sia la tabella del database esterno che l'entità devono essere aggiornate e i campi modificati devono essere rimappati. Sebbene questo metodo sia flessibile e consenta l'uso di diversi tipi di fonti di dati, richiede una pianificazione più anticipata e una manutenzione continua.

Un'entità gestita è un tipo di entità per la quale App Studio gestisce l'intero processo di archiviazione e configurazione dei dati per te. Quando si crea un'entità gestita, viene creata una tabella DynamoDB corrispondente nell'account associato AWS . Ciò garantisce una gestione dei dati sicura e trasparente all'interno. AWS Con un'entità gestita, si configura lo schema dell'entità in App Studio e anche la tabella DynamoDB corrispondente viene aggiornata automaticamente.

Utilizzo di entità gestite in più applicazioni

Una volta creata un'entità gestita in un'app App Studio, tale entità può essere utilizzata in altre app App Studio. Ciò è utile per configurare l'archiviazione dei dati per le app con modelli e schemi di dati identici, fornendo un'unica risorsa sottostante da gestire.

Quando si utilizza un'entità gestita in più applicazioni, tutti gli aggiornamenti dello schema alla tabella DynamoDB corrispondente devono essere effettuati utilizzando l'applicazione originale in cui è stata creata l'entità gestita. Qualsiasi modifica allo schema apportata all'entità in altre applicazioni non aggiornerà la tabella DynamoDB corrispondente.

Limitazioni delle entità gestite

Restrizioni all'aggiornamento della chiave primaria: non è possibile modificare il nome o il tipo di chiave primaria dell'entità dopo la sua creazione, poiché si tratta di una modifica distruttiva in DynamoDB e comporterebbe la perdita dei dati esistenti.

Ridenominazione delle colonne: quando si rinomina una colonna in DynamoDB, si crea effettivamente una nuova colonna mentre la colonna originale rimane con i dati originali. I dati originali non vengono copiati automaticamente nella nuova colonna o eliminati dalla colonna originale. È possibile rinominare i campi delle entità gestite, noti come nome del sistema, ma si perderà l'accesso alla colonna originale e ai relativi dati. La ridenominazione del nome visualizzato non comporta alcuna restrizione.

Modifica del tipo di dati: sebbene DynamoDB consenta la flessibilità di modificare i tipi di dati delle colonne dopo la creazione della tabella, tali modifiche possono influire gravemente sui dati esistenti, nonché sulla logica e sulla precisione delle query. Le modifiche al tipo di dati richiedono la trasformazione di tutti i dati esistenti per renderli conformi al nuovo formato, complesso per tabelle attive di grandi dimensioni. Inoltre, le azioni relative ai dati possono restituire risultati imprevisti fino al completamento della migrazione dei dati. È possibile cambiare i tipi di dati dei campi, ma i dati esistenti non verranno migrati nel nuovo tipo di dati.

Colonna di ordinamento: DynamoDB consente il recupero dei dati ordinati tramite Sort Keys. Le chiavi di ordinamento devono essere definite come parte delle chiavi primarie composite insieme alla chiave di partizione. Le limitazioni includono la chiave di ordinamento obbligatoria, l'ordinamento limitato all'interno di una partizione e nessun ordinamento globale tra le partizioni. È necessaria un'attenta modellazione dei dati di Sort Keys per evitare partizioni a caldo. Non supporteremo la pietra miliare di Sorting for Preview.

Joins: i join non sono supportati in DynamoDB. Le tabelle sono denormalizzate in base alla progettazione per evitare costose operazioni di unione. Per modellare le relazioni uno-a-molti, la tabella figlia contiene un attributo che fa riferimento alla chiave primaria della tabella principale. Multi-table le interrogazioni sui dati comportano la ricerca di elementi dalla tabella principale per recuperare i dettagli. Non supporteremo i join nativi per le entità gestite come parte del traguardo dell'anteprima. Come soluzione alternativa, introdurremo una fase di automazione in grado di eseguire l'unione dei dati di 2 entità. Sarà molto simile a una ricerca a un livello. Non supporteremo la pietra miliare di Sorting for Preview.

Env Stage: consentiremo di testare la pubblicazione, ma utilizzeremo lo stesso archivio gestito in entrambi gli ambienti