Operacje bazodanowe z Codex

Twój product manager chce dashboardu raportowego, który odpytuje pięć tabel z agregacjami, zakresami dat i filtrami na poziomie użytkownika. Istniejące zapytania są już wolne na głównych tabelach, a dodanie złożonych joinów pogorszy sytuację. Potrzebujesz nowego schematu, zoptymalizowanych zapytań, odpowiednich indeksów i migracji, która bezpiecznie działa na produkcyjnej bazie danych z 50 milionami wierszy. Pomyłka oznacza przestój. Codex może zaprojektować schemat, wygenerować migrację, napisać zapytania i przetestować je wobec prawdziwej bazy danych w środowisku chmurowym — wszystko zanim dotkniesz produkcji.

Czego się nauczysz

• Prompty do projektowania schematów, generowania migracji i optymalizacji zapytań z prawdziwymi ORM-ami
• Przepływ pracy w środowisku chmurowym do testowania migracji wobec danych o rozmiarze produkcyjnym
• Przepis na automatyzację cotygodniowych audytów wydajności zapytań
• Techniki używania serwerów MCP do zapewnienia Codex bezpośredniego dostępu do bazy danych podczas rozwoju

Przepływ pracy

Krok 1: Zaprojektuj schemat

Zacznij w CLI lub rozszerzeniu IDE, gdzie możesz szybko iterować. Podaj Codex wymagania i swój istniejący schemat jako kontekst.

Wskazówka

Prompt do skopiowania — projektowanie schematu:

Design database tables for a reporting dashboard. Existing schema is in src/lib/db/schema.ts.

Requirements:
- Users need pre-computed daily summaries of their activity (orders, revenue, refunds)
- Dashboard queries should not hit the main orders table directly
- Support date range filtering (last 7 days, 30 days, custom range)
- Support aggregation by day, week, and month
- Data should be backfillable from existing order records

Design the new tables using Drizzle ORM schema definitions. Include:
1. Table definitions with proper types and constraints
2. Indexes optimized for the dashboard query patterns
3. Foreign key relationships to existing tables
4. Explanation of why you chose this structure over alternatives

Do not generate the migration file yet. Just the schema design for review.

Przejrzyj projekt, zadaj pytania uzupełniające i iteruj. Zmiany schematu są kosztowne do cofnięcia — zainwestuj tu czas.

Krok 2: Wygeneruj migrację

Gdy schemat jest sfinalizowany, wygeneruj migrację w worktree, aby utrzymać ją w izolacji:

Generate a Drizzle migration for the reporting dashboard tables we just designed.

Requirements:
- The migration must be safe to run on a production database with 50M+ rows
- Add tables and indexes in the correct order (tables before indexes, referenced tables before referencing tables)
- Use IF NOT EXISTS for safety
- Include a DOWN migration that cleanly drops everything
- Follow the migration naming convention in drizzle/migrations/

After generating the migration, run it against the dev database to verify it applies cleanly.
Do NOT populate data. We will handle backfill separately.

Krok 3: Napisz zoptymalizowane zapytania

Zapytania bazodanowe to obszar, w którym zdolność Codex do odczytania całego schematu się opłaca. Może pisać zapytania uwzględniające indeksy, strategie joinów i faktyczne API ORM-a.

Wskazówka

Prompt do skopiowania — generowanie zapytań:

Write Drizzle ORM queries for the reporting dashboard in src/lib/db/queries/reports.ts:

1. getDailySummary(userId, startDate, endDate) - returns daily aggregates
2. getWeeklySummary(userId, startDate, endDate) - returns weekly aggregates
3. getMonthlyTrend(userId, months) - returns month-over-month comparison
4. getTopProducts(userId, startDate, endDate, limit) - top products by revenue
5. getRefundRate(userId, startDate, endDate) - refund percentage

For each query:
- Use the Drizzle query builder (not raw SQL)
- Use the indexes we defined (check the schema for available indexes)
- Include proper type annotations for return values
- Handle edge cases: no data in range, timezone handling, null aggregates

Read our existing query patterns in src/lib/db/queries/ for style conventions.

Krok 4: Zasil dane testowe

Kompleksowe dane testowe umożliwiają weryfikację zapytań i wykrywanie problemów wydajnościowych przed produkcją. Wygeneruj skrypt zasilania:

Create a database seeding script at scripts/seed-reports.ts that:

1. Creates 100 test users
2. Generates 6 months of order data (varying volume per user, per day)
3. Includes realistic patterns: weekday vs weekend variation, seasonal trends, some users with refunds
4. Populates the daily summary table from the generated orders
5. Is idempotent (safe to run multiple times)

Use Drizzle for inserts. Use batched inserts (chunks of 1000) for performance.
The script should be runnable via: npx tsx scripts/seed-reports.ts

Krok 5: Testuj migracje w chmurze

Przed uruchomieniem migracji na staging lub produkcji przetestuj je w środowisku chmurowym, które odzwierciedla twoje ustawienie produkcyjne. Środowiska chmurowe obsługują skrypty konfiguracyjne, gdzie możesz zainstalować bazę danych, uruchomić migracje i zasilić dane.

Skonfiguruj środowisko chmurowe ze skryptem konfiguracyjnym:

# Install dependencies
npm install

# Start PostgreSQL
pg_ctl start

# Run all existing migrations
npm run db:migrate

# Seed with production-scale test data
npx tsx scripts/seed-reports.ts

Następnie prześlij zadanie w chmurze:

codex cloud exec --env db-test "Run the new reporting dashboard migration. After it completes, execute each of the 5 dashboard queries from src/lib/db/queries/reports.ts against the seeded data. Report:
1. Whether each query returns correct results
2. Execution time for each query
3. EXPLAIN ANALYZE output for the two slowest queries
4. Any missing indexes or full table scans

If any query takes longer than 500ms, suggest optimizations."

Audyt wydajności z automatyzacjami

Skonfiguruj cotygodniową automatyzację monitorującą wydajność zapytań:

Wskazówka

Prompt automatyzacji do skopiowania — audyt wydajności zapytań:

Run all database queries in src/lib/db/queries/ against the dev database with EXPLAIN ANALYZE. For each query:

1. Report execution time
2. Flag any sequential scans on tables with more than 10,000 rows
3. Flag any queries that do not use available indexes
4. Flag any N+1 query patterns in the service layer

If performance degraded compared to last week's audit, investigate which recent code changes caused the regression. Report findings with specific file paths and line numbers.

Używanie MCP do bezpośredniego dostępu do bazy danych

Jeśli chcesz, aby Codex odpytywał twoją bazę danych bezpośrednio podczas rozwoju (nie tylko generował kod), skonfiguruj serwer MCP PostgreSQL:

~/.codex/config.toml

[mcp_servers.postgres]
type = "stdio"
command = "npx"
args = ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost:5432/mydb"]

Z podłączonym serwerem MCP Codex może wykonywać zapytania podczas sesji, inspekcjonować rzeczywiste dane i weryfikować wyniki bez konieczności ręcznego uruchamiania zapytań przez ciebie.

Kiedy to nie działa

Migracja działa na dev, ale nie na danych produkcyjnych. Dodanie indeksu na tabeli z 50 milionami wierszy może trwać minuty i blokować tabelę. Powiedz Codex: “Generate the index creation with CONCURRENTLY for PostgreSQL so it does not lock the table. Include a note about expected duration based on table size.”

Zapytania generowane przez ORM są nieefektywne. Drizzle (i inne ORM-y) czasami generują nieoptymalny SQL. Uwzględnij “check the generated SQL for each query using .toSQL() and verify it uses the expected indexes” w swoim prompcie. Dla krytycznych zapytań rozważ surowy SQL opakowany w wywołanie execute Drizzle.

Środowisko chmurowe nie ma wystarczających danych, aby ujawnić problemy wydajnościowe. Skrypt zasilania generuje 100 użytkowników z 6 miesiącami danych, ale produkcja ma 100 tysięcy użytkowników z 3 latami danych. Przeskaluj skrypt zasilania proporcjonalnie lub jawnie testuj z EXPLAIN ANALYZE wobec statystyk tabel produkcyjnych.

Obsługa stref czasowych w agregacjach dat. Zapytania z zakresami dat, które nie uwzględniają stref czasowych, produkują nieprawidłowe wyniki dla użytkowników w różnych strefach. Uwzględnij “all date-range queries must accept and handle timezone-aware timestamps. Store in UTC, convert for display” w swoich ograniczeniach.

Co dalej

Automatyzacja wdrożeń z Codex Wdrażaj zmiany bazodanowe obok aktualizacji aplikacji

Optymalizacja wydajności Profiluj i optymalizuj zapytania i systemy, które zbudowałeś