Möchten Sie dies nicht manuell einrichten? Fügen Sie einen Link zu dieser Seite in eine Devin-Sitzung ein und bitten Sie Devin, alles für Sie einzurichten. Analysieren Sie Ihre MongoDB-Collections und entwerfen Sie relationale Entsprechungen. Wenn Ihre Daten mehrere Collections mit Beziehungen umfassen, erstellen Sie zunächst ein Entity-Relationship-Diagramm, um Normalisierungsentscheidungen zu validieren, bevor Sie SQL schreiben. Wichtige Übersetzungsmuster: * **Document IDs**: MongoDB-`_id`-Felder in UUID- oder SERIAL-Primärschlüssel umwandeln * **Verschachtelte Objekte**: In separate Tabellen mit Fremdschlüsselbeziehungen aufteilen * **Arrays**: Postgres-Array-Typen oder separate Verknüpfungstabellen verwenden * **Eingebettete Dokumente**: In zugehörige Tabellen mit korrekter Normalisierung auslagern ```txt Analyze MongoDB schema and design Postgres tables theme={null} Analysieren Sie unsere bestehenden MongoDB-Collections und Dokumentenschemata. Für jede Collection: 1. Entwerfen Sie eine äquivalente PostgreSQL-Tabelle mit passenden Spaltentypen 2. Identifizieren Sie Beziehungen und erstellen Sie Fremdschlüssel 3. Entflechten Sie verschachtelte Objekte bei Bedarf in separate Tabellen 4. Erstellen Sie ein ERD, das alle Entitäten und Beziehungen zeigt 5. Wandeln Sie MongoDB ObjectIds in UUIDs um 6. Schreiben Sie die SQL-Migration zur Erstellung des Schemas ``` Wenn das Schema fertig ist, richten Sie die Sicherheit ein: Erstellen Sie Postgres-Rollen mit geeigneten Berechtigungen und aktivieren Sie Row-Level-Security-(RLS)-Richtlinien für Tabellen, die Zugriffskontrolle auf Zeilenebene benötigen. Ersetze deinen MongoDB-Treiber (z. B. `mongoose`, `mongodb`) durch eine Postgres-Clientbibliothek — Prisma, Drizzle, TypeORM oder `node-postgres`, je nach Stack. Aktualisiere deine Umgebungskonfiguration mit `DATABASE_URL` oder gleichwertigen Verbindungsdaten. Muster für die Migration deiner Queries: * **Find-Operationen** → SQL-`SELECT`-Queries oder ORM-Methoden wie `.findMany()` / `.select()` * **Aggregation-Pipelines** → `JOIN`s, `GROUP BY`, Unterabfragen, Window-Funktionen * **Updates** → SQL-`UPDATE`-Statements * **Inserts** → SQL-`INSERT` oder Bulk-Insert-Methoden ```txt Migrate backend from MongoDB to Postgres theme={null} Replace our MongoDB driver with [Prisma / Drizzle / node-postgres]. For each backend module: 1. Replace MongoDB imports and connection setup 2. Rewrite all queries to use the new Postgres client 3. Update error handling (e.g. unique constraint violations are Postgres code 23505) 4. Preserve all existing API response formats 5. Run tests after each module to verify nothing breaks ``` Wenn deine App eine benutzerdefinierte JWT-Authentifizierung mit einem MongoDB-User-Store verwendet, passe die User-Lookup-Queries auf Postgres an, während du die bestehende Logik zur Token-Erzeugung und -Validierung beibehältst. Aktualisieren Sie Frontend-Services, damit sie alle Änderungen an den Datenstrukturen durch die Migration verarbeiten können — am häufigsten wird `_id` zu `id`. Behalten Sie die bestehenden Signaturen der Servicemethoden bei, damit Komponenten nicht geändert werden müssen. * Aktualisieren Sie Authentifizierungs-Services, falls sich der Auth-Flow geändert hat * Passen Sie die Request-/Response-Verarbeitung des HTTP-Clients an die neuen Datenstrukturen an * Aktualisieren Sie Route Guards und Resolver, wenn sich Muster beim Datenabruf geändert haben Exportieren Sie Ihre MongoDB-Daten, passen Sie sie an das Postgres-Schema an und importieren Sie sie. ```txt Erstellen Sie ein Datenmigrationsskript theme={null} Schreiben Sie ein Migrationsskript, das: 1. Daten aus unseren MongoDB-Collections exportiert 2. Dokumente so transformiert, dass sie dem PostgreSQL-Schema entsprechen (ObjectId → UUID, eingebettete Dokumente auflösen, Datumsangaben konvertieren) 3. Daten in PostgreSQL importiert und Fremdschlüsselbeziehungen beibehält 4. Die Datenintegrität überprüft: Zeilenanzahlen, Schlüsselbeziehungen, Stichprobenprüfungen ``` Führen Sie nach dem Import die vollständige Test-Suite gegen das Postgres-Backend aus. Überprüfen Sie, dass alle CRUD-Operationen, Authentifizierungsabläufe und rollenbasierten Zugriffe korrekt funktionieren. Deployment mit Feature Flags für einen schrittweisen Rollout durchführen. Die MongoDB-Instanz während der Übergangsphase als Fallback beibehalten. Checkliste nach dem Deployment: * Indizes für häufig abgefragte Spalten hinzufügen * `EXPLAIN ANALYZE` verwenden, um langsame Abfragen zu identifizieren * Connection-Pooling einrichten (z. B. PgBouncer) * Abfrageleistung und Auslastung der Verbindungen überwachen * Rollback-Verfahren für kritische Probleme dokumentieren ```txt Optimierung nach der Migration theme={null} Die Migration von MongoDB zu Postgres ist bereitgestellt. Führe EXPLAIN ANALYZE für unsere häufigsten Abfragen aus und schlage Indizes vor. Prüfe: 1. Sequentielle Scans auf großen Tabellen, die Indizes verwenden sollten 2. Fehlende Indizes auf Fremdschlüsselspalten 3. Abfragen, die von partiellen oder zusammengesetzten Indizes profitieren könnten 4. Empfehlungen zur Größe des Connection-Pools auf Basis unserer Workload ``` Sobald alles stabil ist und verifiziert wurde, die MongoDB-Instanz außer Betrieb nehmen. Wenn Sie dieses Migrationsmuster für mehrere Dienste oder Repositories ausführen müssen, speichern Sie es als [Playbook](/de/product-guides/creating-playbooks), damit jede Sitzung denselben Prozess durchläuft. Nachfolgend finden Sie ein Beispiel-Playbook für eine Migration von MongoDB zu Postgres: ```txt MongoDB to PostgreSQL Migration theme={null} ## Übersicht Migration eines Projekts von MongoDB zu PostgreSQL. Dies umfasst Schema-Design, Backend-API-Migration, Aktualisierungen der Frontend-Service-Schicht, Datenmigration und Deployment. ## Erforderliche Angaben vom Benutzer - Zugriff auf die MongoDB-Quelldatenbank (Verbindungszeichenfolge oder Export) - Zugangsdaten der PostgreSQL-Zieldatenbank (Host, Port, Datenbank, Benutzer, Passwort) - Beschreibung des Datenmodells der Anwendung und der wichtigsten Abfragen - Authentifizierungs-/Autorisierungsanforderungen für das neue System ## Phase 1: Datenbankschema-Design & Einrichtung ### Schritt 1: Projekteinrichtung 1. PostgreSQL-Datenbank bereitstellen und Verbindungsdaten notieren 2. Vorhandene MongoDB-Collections und Dokumentschemata analysieren 3. Äquivalente PostgreSQL-Tabellen mit geeigneten Beziehungen entwerfen ### Schritt 2: ERD-Erstellung Wenn das MongoDB-Quellschema mehrere Collections mit Beziehungen umfasst (eingebettete Dokumente, Referenzen über ObjectIds oder Junction-Muster), vor dem Entwurf der PostgreSQL-Tabellen ein Entity-Relationship-Diagramm erstellen: 1. Alle Entitäten und ihre Attribute aus den MongoDB-Collections identifizieren 2. Beziehungen zwischen Entitäten abbilden (1:1, 1:n, m:n) 3. Ein ERD mit einem Tool wie dbdiagram.io, Mermaid oder draw.io erstellen 4. Das ERD zur Validierung von Normalisierungsentscheidungen und Fremdschlüssel-Design verwenden, bevor SQL geschrieben wird Diesen Schritt überspringen, wenn die Migration nur eine einzelne Collection oder einige wenige unabhängige Collections ohne nennenswerte Beziehungen umfasst. ### Schritt 3: Schema-Übersetzungsmuster - Dokument-IDs: MongoDB-_id-Felder in PostgreSQL-UUID- oder SERIAL-Primärschlüssel umwandeln - Verschachtelte Objekte: In separate Tabellen mit Fremdschlüssel- beziehungen überführen - Arrays: PostgreSQL-Array-Typen oder separate Junction-Tabellen verwenden - Eingebettete Dokumente: In verknüpfte Tabellen mit geeigneter Normalisierung auslagern ### Schritt 4: Sicherheitskonfiguration 1. PostgreSQL-Rollen und -Benutzer mit geeigneten Berechtigungen erstellen (read-only, read-write, Admin) 2. GRANT/REVOKE verwenden, um Tabellen- und Spaltenzugriff je Rolle einzuschränken 3. Falls die Anwendung zeilenbasierte Zugriffskontrolle benötigt, Row Level Security (RLS)-Richtlinien für relevante Tabellen aktivieren ### Schritt 5: Datenbankfunktionen & Trigger 1. Benutzerverwaltungs-Trigger für automatische Datensatzerstellung anlegen (z. B. Audit-Zeitstempel, Standardwerte) 2. Geschäftslogikfunktionen in PL/pgSQL implementieren, um Validierungen auf Anwendungsebene wo sinnvoll zu ersetzen ## Phase 2: Backend-API-Migration ### Schritt 1: Abhängigkeitsverwaltung 1. MongoDB-Treiber (z. B. mongodb, mongoose) durch eine PostgreSQL-Client-Bibliothek ersetzen (z. B. pg für Node.js, psycopg2 für Python oder ein ORM wie Prisma/Sequelize/TypeORM) 2. Umgebungskonfiguration mit PostgreSQL-Verbindungsdaten aktualisieren (DATABASE_URL oder einzelne Host/Port/DB/Benutzer/ Passwort-Variablen) 3. MongoDB-spezifische Middleware oder Hilfsprogramme entfernen oder ersetzen ### Schritt 2: Aktualisierungen des Authentifizierungssystems 1. Falls die bestehende App benutzerdefinierte JWT-Authentifizierung verwendet, diese beibehalten und die Benutzerabfragen auf PostgreSQL umstellen 2. Bei Migration zu einem neuen Authentifizierungssystem Middleware für Token-Generierung und -Validierung entsprechend ersetzen 3. Bestehende API-Antwortformate für Frontend-Kompatibilität beibehalten ### Schritt 3: Abfrage-Migrationsmuster - Suchoperationen: collection.find() in SQL-SELECT-Abfragen umwandeln (oder ORM-Äquivalente wie .findMany(), .select()) - Aggregations-Pipelines: Durch PostgreSQL-JOINs, GROUP BY, Unterabfragen und Fensterfunktionen ersetzen - Aktualisierungen: updateOne/updateMany in SQL-UPDATE-Anweisungen umwandeln - Einfügungen: insertOne/insertMany durch SQL-INSERT-Anweisungen oder Bulk-Insert-Methoden ersetzen ### Schritt 4: Aktualisierungen der Fehlerbehandlung 1. MongoDB-spezifische Fehlercodes durch PostgreSQL-Fehlerbehandlung ersetzen (z. B. Verletzungen von Eindeutigkeitsbeschränkungen haben Code 23505) 2. Einheitliche Fehlerantwortformate für Frontend-Services beibehalten ## Phase 3: Aktualisierungen der Frontend-Service-Schicht ### Schritt 1: Migration des Authentifizierungsdienstes 1. Benutzerauthentifizierungsdienst aktualisieren, um mit den neuen Backend-Authentifizierungsendpunkten zu arbeiten 2. Bei geändertem Authentifizierungsansatz Login-/Logout-Abläufe und Token-Verwaltung entsprechend aktualisieren 3. Benutzerobjekterstellung anpassen, um mit dem neuen Benutzerdatenformat aus PostgreSQL zu arbeiten ### Schritt 2: HTTP-Client-Aktualisierungen 1. API-Endpunkt-URLs aktualisieren, falls sich die Backend-Struktur ändert 2. Anfrage-/Antwortverarbeitung anpassen, falls sich Datenstrukturen geändert haben (z. B. _id wird zu id) 3. Bestehende Service-Methodensignaturen für Komponentenkompatibilität beibehalten ### Schritt 3: Aktualisierungen von Route Guards & Resolvern 1. Authentifizierungs-Guards aktualisieren, um mit dem neuen Authentifizierungssystem zu arbeiten 2. Routen-Resolver anpassen, falls sich Datenabrufmuster geändert haben 3. Sicherstellen, dass bestehende Komponentendatenflüsse intakt bleiben ## Phase 4: Datenmigration & Tests ### Schritt 1: Datenexport & Transformation 1. MongoDB-Collections mit mongoexport oder benutzerdefinierten Skripten exportieren 2. Daten transformieren, um den PostgreSQL-Schema-Anforderungen zu entsprechen 3. Datentypkonvertierungen durchführen (ObjectId zu UUID, Datumsangaben, eingebettete Dokumente zu Fremdschlüsseln usw.) ### Schritt 2: Datenimportprozess 1. Daten mit psql \copy, pg_restore oder benutzerdefinierten Migrationsskripten importieren 2. Fremdschlüsselbeziehungen und Constraints nach dem Import überprüfen 3. Zählungen und Stichprobenprüfungen durchführen, um Datenintegrität und Vollständigkeit zu bestätigen ### Schritt 3: End-to-End-Tests 1. Alle CRUD-Operationen mit echten Daten testen 2. Sicherstellen, dass Authentifizierungsabläufe korrekt funktionieren 3. Admin-Funktionalität und rollenbasierte Zugriffskontrolle testen ## Phase 5: Deployment & Monitoring ### Schritt 1: Deployment-Strategie 1. Backend-Änderungen mit Feature-Flags für schrittweises Rollout deployen 2. Frontend-Konfiguration für produktive PostgreSQL-gestützte Endpunkte aktualisieren 3. Datenbankverbindungs-Pooling (z. B. PgBouncer) und Monitoring implementieren ### Schritt 2: Leistungsoptimierung 1. Datenbankindizes für häufig abgefragte Spalten hinzufügen 2. EXPLAIN ANALYZE verwenden, um langsame Abfragen zu identifizieren und zu optimieren 3. Abfrageleistung und Verbindungspool-Auslastung überwachen ### Schritt 3: Rollback-Planung 1. MongoDB-Instanz während der Übergangsphase als Backup beibehalten 2. Rollback-Verfahren für kritische Probleme dokumentieren 3. Datensynchronisierungsskripte bei Bedarf erstellen ## Wichtige Migrationsmuster ### Authentifizierungsmigration - Von: Benutzerdefiniertes JWT mit MongoDB-Benutzerspeicher - Zu: Benutzerdefiniertes JWT (oder Framework-Authentifizierung) mit PostgreSQL-Benutzerspeicher - Beibehalten: Bestehende Benutzerobjekt-Schnittstellen und Komponentenverträge ### Datenbankabfrage-Migration - Von: MongoDB-Aggregations-Pipelines und Dokumentabfragen - Zu: SQL-Abfragen mit JOINs, GROUP BY und Fensterfunktionen - Beibehalten: API-Antwortformate und Datenstrukturen ### Sicherheitsmigration - Von: Autorisierung auf Anwendungsebene mit MongoDB - Zu: PostgreSQL-Rollen/Berechtigungen plus optionale RLS-Richtlinien - Beibehalten: Benutzerrollen- und Berechtigungslogik ## Spezifikationen - Alle bestehenden API-Verträge und Antwortformate müssen beibehalten werden - Datenintegrität muss nach der Migration überprüft werden (Zeilenanzahlen, Schlüsselbeziehungen, Stichprobenprüfungen) - Die MongoDB-Instanz sollte während der Übergangsphase als Fallback verfügbar bleiben - Validierung: Die Test-Suite der Anwendung vollständig gegen das PostgreSQL-Backend ausführen und bestätigen, dass alle Tests bestanden werden ```

{title}