Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwaltete Datenentitäten in AWS App Studio

Normalerweise konfigurieren Sie eine Entität in App Studio mit einer Verbindung zu einer externen Datenbanktabelle, und Sie müssen jedes Entitätsfeld erstellen und einer Spalte in der verbundenen Datenbanktabelle zuordnen. Wenn Sie eine Änderung am Datenmodell vornehmen, müssen sowohl die externe Datenbanktabelle als auch die Entität aktualisiert werden, und die geänderten Felder müssen neu zugeordnet werden. Diese Methode ist zwar flexibel und ermöglicht die Verwendung verschiedener Arten von Datenquellen, erfordert jedoch mehr Vorausplanung und laufende Wartung.

Eine verwaltete Entität ist eine Art von Entität, für die App Studio den gesamten Datenspeicher- und Konfigurationsprozess für Sie verwaltet. Wenn Sie eine verwaltete Entität erstellen, wird eine entsprechende DynamoDB-Tabelle im zugehörigen AWS Konto erstellt. Dies gewährleistet eine sichere und transparente Datenverwaltung im Inneren. AWS Bei einer verwalteten Entität konfigurieren Sie das Schema der Entität in App Studio, und die entsprechende DynamoDB-Tabelle wird ebenfalls automatisch aktualisiert.

Verwenden verwalteter Entitäten in mehreren Anwendungen

Sobald Sie eine verwaltete Entität in einer App Studio-App erstellt haben, kann diese Entität in anderen App Studio-Apps verwendet werden. Dies ist hilfreich für die Konfiguration des Datenspeichers für Apps mit identischen Datenmodellen und Schemas, da eine einzige zugrundeliegende Ressource zur Verwaltung bereitgestellt wird.

Wenn Sie eine verwaltete Entität in mehreren Anwendungen verwenden, müssen alle Schemaaktualisierungen der entsprechenden DynamoDB-Tabelle mit der ursprünglichen Anwendung vorgenommen werden, in der die verwaltete Entität erstellt wurde. Durch Schemaänderungen, die in anderen Anwendungen an der Entität vorgenommen werden, wird die entsprechende DynamoDB-Tabelle nicht aktualisiert.

Einschränkungen bei verwalteten Entitäten

Einschränkungen bei der Aktualisierung von Primärschlüsseln: Sie können den Primärschlüsselnamen oder -typ der Entität nach ihrer Erstellung nicht mehr ändern, da dies eine destruktive Änderung in DynamoDB darstellt und zum Verlust vorhandener Daten führen würde.

Umbenennen von Spalten: Wenn Sie eine Spalte in DynamoDB umbenennen, erstellen Sie tatsächlich eine neue Spalte, während die ursprüngliche Spalte mit den Originaldaten verbleibt. Die Originaldaten werden nicht automatisch in die neue Spalte kopiert oder aus der ursprünglichen Spalte gelöscht. Sie können verwaltete Entitätsfelder, die als Systemnamen bezeichnet werden, umbenennen, aber Sie verlieren den Zugriff auf die ursprüngliche Spalte und ihre Daten. Es gibt keine Einschränkung beim Umbenennen des Anzeigenamens.

Änderung des Datentyps: DynamoDB bietet zwar die Flexibilität, Spaltendatentypen nach der Tabellenerstellung zu ändern, doch solche Änderungen können die vorhandenen Daten sowie die Abfragelogik und Genauigkeit erheblich beeinträchtigen. Bei Änderungen des Datentyps müssen alle vorhandenen Daten so transformiert werden, dass sie dem neuen Format entsprechen, was bei großen, aktiven Tabellen komplex ist. Darüber hinaus können Datenaktionen zu unerwarteten Ergebnissen führen, bis die Datenmigration abgeschlossen ist. Sie können die Datentypen von Feldern wechseln, aber die vorhandenen Daten werden nicht auf den neuen Datentyp migriert.

Sortierspalte: DynamoDB ermöglicht das Abrufen sortierter Daten mithilfe von Sortierschlüsseln. Sortierschlüssel müssen zusammen mit dem Partitionsschlüssel als Teil zusammengesetzter Primärschlüssel definiert werden. Zu den Einschränkungen gehören ein obligatorischer Sortierschlüssel, eine auf eine Partition beschränkte Sortierung und keine globale Sortierung zwischen Partitionen. Eine sorgfältige Datenmodellierung der Sortierschlüssel ist erforderlich, um heiße Partitionen zu vermeiden. Wir werden den Meilenstein Sorting for Preview nicht unterstützen.

Joins: Joins werden in DynamoDB nicht unterstützt. Tabellen sind standardmäßig denormalisiert, um teure Join-Operationen zu vermeiden. Um Eins-zu-Viele-Beziehungen zu modellieren, enthält die untergeordnete Tabelle ein Attribut, das auf den Primärschlüssel der übergeordneten Tabelle verweist. Multi-table Bei Datenabfragen wird nach Elementen aus der übergeordneten Tabelle gesucht, um Details abzurufen. Im Rahmen des Preview-Meilensteins werden wir keine systemeigenen Joins für verwaltete Entitäten unterstützen. Um das Problem zu umgehen, werden wir einen Automatisierungsschritt einführen, der eine Datenzusammenführung von 2 Entitäten durchführen kann. Dies wird einer Suche auf einer Ebene sehr ähnlich sein. Wir werden den Meilenstein Sorting for Preview nicht unterstützen.

Env Stage: Wir werden das Veröffentlichen zu Testzwecken zulassen, aber in beiden Umgebungen den gleichen verwalteten Speicher verwenden