Wzorce rozwoju baz danych

Zapytanie raportowe, które na staging skanowało kilka tysięcy wierszy, teraz sekwencyjnie skanuje 40 milionów na produkcji i wykłada dashboard timeoutem. „Szybka” zmiana nazwy kolumny wypuszcza migrację, która zakłada blokadę ACCESS EXCLUSIVE i zamraża każdy zapis na dziewięćdziesiąt sekund. A relacja ORM dodana w zeszłym tygodniu po cichu odpala jedno zapytanie na wiersz, więc strona zamówień wykonuje 500 rund w obie strony, by się wyrenderować. To awarie baz danych, które nie ujawniają się, dopóki nie pojawią się prawdziwe dane i prawdziwa współbieżność — i to tu agent kodujący jest naprawdę użyteczny, bo poprawka to rozpoznawalny wzorzec, a nie wynalazek.

Ten przepis pokazuje prompty, które skłaniają AI do odczytania faktycznego planu EXPLAIN ANALYZE, zaproponowania bezpiecznej migracji expand/contract i zwinięcia N+1 w jedno zapytanie wsadowe. Bazowy stack to PostgreSQL z Drizzle ORM, ale prompty sprawdzają się równie dobrze z Prismą lub czystym SQL-em.

Co z tego wyniesiesz

• Prompt, który wkleja prawdziwy plan EXPLAIN (ANALYZE, BUFFERS) i dostaje z powrotem ukierunkowane rekomendacje indeksów, a nie ogólnikowe porady.
• Prompt do zmiany nazwy kolumny bez przestoju wykorzystujący wzorzec expand/contract, dzięki czemu zapisy nigdy się nie blokują.
• Prompt, który zamienia wzorzec dostępu N+1 w ORM w jedno zapytanie wsadowe.
• Trójnarzędziowy workflow pracy ze schematem (Cursor, Claude Code, Codex) i jak zmienia go serwer MCP dla Postgresa.
• Listę kontrolną „Gdy to się psuje” dla złych porad, jakich modele AI udzielają przy pracy z bazą danych.

Projektowanie schematu w trzech narzędziach

Generowanie schematu to jedno zadanie, w którym wszystkie trzy narzędzia robią z grubsza to samo — czytają Twoje istniejące tabele, dopasowują konwencje, proponują nowe. Różnica leży w powierzchni, z której to napędzasz.

Cursor

Otwórz swój istniejący plik schematu (src/db/schema.ts), aby tryb Agent miał go w kontekście, następnie Cmd/Ctrl + I:

Zgodnie z konwencjami Drizzle w @src/db/schema.ts, dodaj tabele orders i order_items. Uwzględnij created_at/updated_at z domyślnymi wartościami, deleted_at dla soft delete, klucz obcy z order_items do orders z ON DELETE CASCADE oraz indeks na orders(user_id, created_at DESC) dla naszego najczęstszego wyszukiwania.

Przejrzyj diff przed zaakceptowaniem i użyj Checkpointu, abyś mógł cofnąć całą zmianę schematu, jeśli wybór indeksu jest błędny.

Claude Code

Pozwól Claude Code samodzielnie odczytać schemat i historię migracji:

claude "Read src/db/schema.ts and the latest files in drizzle/, then add orders and \
order_items tables matching our conventions: timestamps, soft delete, FK with cascade, \
and an index on orders(user_id, created_at DESC). Generate the Drizzle migration too."

Dodaj --permission-mode plan, by zaproponował schemat i migrację, zanim cokolwiek zapisze.

Codex

Uruchom zmianę nieinteraktywnie, by wylądowała jako jeden commit do przejrzenia:

codex exec --ask-for-approval on-request \
"Add orders and order_items tables to src/db/schema.ts following our Drizzle conventions \
(timestamps, soft delete, FK cascade, index on orders(user_id, created_at DESC)) and \
generate the migration."

Codex Cloud sprawdza się lepiej, gdy migracja jest ryzykowna: uruchamia zadanie w izolowanym worktree i otwiera PR, więc możesz przejrzeć wygenerowany SQL, zanim dotknie współdzielonej gałęzi.

Notatka

Konkretnie przy pracy z zapytaniami serwer MCP dla Postgresa zmienia pętlę: zamiast wklejać plan EXPLAIN ręcznie, agent łączy się z Twoją bazą tylko do odczytu i samodzielnie pobiera plan, statystyki tabel i istniejące indeksy. Sięgnij po utrzymywany — Postgres MCP Pro (crystaldba/postgres-mcp) jest stworzony specjalnie do tego, z narzędziami do strojenia indeksów i analizy planów EXPLAIN; Neon i Supabase dostarczają własne, jeśli korzystasz z tych platform. (Unikaj dawno zarchiwizowanego @modelcontextprotocol/server-postgres — jest przestarzały i był przedmiotem udokumentowanego studium przypadku SQL injection.) Skonfiguruj go raz, a integracja jest identyczna w Cursor, Claude Code i Codex — wskaż go na replikę do odczytu lub rolę z ograniczeniem połączeń, nigdy na bazę główną z poświadczeniami do zapisu.

Optymalizacja wolnego zapytania na podstawie jego prawdziwego planu

Największym ulepszeniem strojenia zapytań przez AI jest odmowa pozwolenia mu na zgadywanie. Model, któremu podasz sam SQL, dopasuje wzorzec („dodaj indeks na kolumnach WHERE”) i często się myli. Model, któremu podasz faktyczny plan wykonania, widzi skanowanie sekwencyjne, błąd w szacowaniu liczby wierszy i sortowanie zrzucane na dysk — i rekomenduje indeks, który pasuje.

Wskazówka

Prompt do wklejenia — rekomendacja indeksu na podstawie prawdziwego planu:

Here is a slow query and its EXPLAIN (ANALYZE, BUFFERS) output on Postgres 16.

SELECT o.id, o.total, u.email
FROM orders o
JOIN users u ON u.id = o.user_id
WHERE o.status = 'pending'
  AND o.created_at > NOW() - INTERVAL '30 days'
ORDER BY o.created_at DESC
LIMIT 50;

[paste the full EXPLAIN ANALYZE output here]

Tell me:

1. Which node is the bottleneck and why (cite the actual vs. estimated rows and the buffers read).
2. The single most effective index to add, written as a CREATE INDEX CONCURRENTLY statement.
3. Whether a partial index (WHERE status = 'pending') wins here, given the selectivity.
4. The expected plan change after the index — which scan should replace the seq scan.

Do not suggest more than two indexes, and justify each against the plan.

Dyscyplina, która czyni to niezawodnym: poproś jawnie o CREATE INDEX CONCURRENTLY (zwykły CREATE INDEX blokuje zapisy na dużej tabeli) i wymagaj uzasadnienia względem planu. Jeśli AI rekomenduje cztery indeksy „dla bezpieczeństwa”, sprzeciw się — każdy indeks to podatek od czasu zapisu, a model nie ma pojęcia o Twoim wolumenie zapisów, dopóki mu nie powiesz.

Migracje bez przestoju: wzorzec expand/contract

Zmiana nazwy kolumny przez ALTER TABLE ... RENAME COLUMN wygląda niewinnie i jest w porządku na małych tabelach, ale na gorącej tabeli blokada plus przebudowa zależnych widoków może zatrzymać produkcję. Bezpiecznym wzorcem jest expand/contract: dodaj nową kolumnę, uzupełnij dane (backfill), pisz podwójnie z aplikacji, przełącz odczyty, a następnie usuń starą kolumnę w późniejszym wdrożeniu. AI zna ten wzorzec — Twoim zadaniem jest sprawić, by wyprodukowało wszystkie kroki, a nie samą zmianę nazwy.

Wskazówka

Prompt do wklejenia — zmiana nazwy kolumny w trybie expand/contract:

We need to rename users.full_name to users.display_name on a table with ~20M rows and constant write traffic, with zero downtime, using Drizzle migrations on Postgres. Produce the migration sequence as separate, independently deployable steps:

1. Expand: add display_name (nullable, no default to avoid a full rewrite) and a trigger that copies full_name -> display_name on insert/update.
2. Backfill: a batched UPDATE (e.g. 5,000 rows per batch by id range) so we never lock the whole table; show the loop or the batching SQL.
3. Contract: after the app reads display_name, drop the trigger and full_name in a final migration.

For each step, note exactly what lock it takes and whether it’s safe to run during peak traffic. Flag any step that would take an ACCESS EXCLUSIVE lock.

Wypatruj modelu zwijającego to w pojedynczy RENAME „bo to prostsze”. Jest prostsze — i to właśnie ta rzecz, która wyrwie Cię z łóżka o drugiej w nocy. Backfill wsadowy to część najczęściej brakująca — bez niego jeden wielki UPDATE przepisuje każdy wiersz pod blokadą i właśnie przywróciłeś przestój, którego unikałeś.

Zabicie N+1 jednym zapytaniem wsadowym

ORM-y sprawiają, że N+1 pisze się bezwysiłkowo: iterujesz po liście, dotykasz relacji i już odpaliłeś jedno zapytanie na element. Rozwiązaniem jest załadowanie potomków jednym zapytaniem kluczowanym po ID rodzica. Daj AI kod sprawcy i model, a przekształci wzorzec dostępu.

Wskazówka

Prompt do wklejenia — zwiń N+1 w jedno zapytanie:

This Drizzle code triggers an N+1 — one query per order to load its items:

const orders = await db.select().from(ordersTable).where(eq(ordersTable.userId, userId));
for (const order of orders) {
  order.items = await db.select().from(itemsTable).where(eq(itemsTable.orderId, order.id));
}

Rewrite it to load all items in a single query using inArray(itemsTable.orderId, ids), then group them in memory by orderId so each order still ends up with its items array. Preserve the exact return shape the callers expect. Then show the two SQL statements this issues (one for orders, one for items) and confirm it’s O(2), not O(n+1).

Krok weryfikacji — „pokaż dwa zapytania SQL” — ma znaczenie, bo niektóre przepisania AI zamieniają N+1 na pojedyncze zapytanie ze złączeniem kartezjańskim, które przesyła te same dane wiersza N razy przez sieć. Dwa czyste zapytania zgrupowane w pamięci to kształt, jakiego chcesz.

Gdy to się psuje

Uwaga

Złe porady, jakich modele AI udzielają przy pracy z bazą danych — wyłap je na code review:

• Spam indeksami. Poproszone o „optymalizację”, modele dodają indeksy na każdej kolumnie WHERE/ORDER BY. Każdy spowalnia zapisy i rozdyma storage. Nalegaj na jeden lub dwa, uzasadnione względem faktycznego planu.
• CREATE INDEX bez CONCURRENTLY. Zwykłe budowanie indeksu blokuje tabelę przed zapisami. Na każdej dużej, żywej tabeli wymagaj CONCURRENTLY (i pamiętaj, że nie może działać wewnątrz bloku transakcji).
• Migracje niewspółbieżne / jednostrzałowe. Model proponuje goły RENAME lub niewsadowy UPDATE, który blokuje gorącą tabelę. Wymagaj kroków expand/contract i wsadowego backfillu oraz poproś, by nazwał blokadę zakładaną przez każdy krok.
• Halucynowane rozszerzenia i funkcje. Wypatruj wymyślonych rozszerzeń lub funkcji Postgresa (wiarygodnie brzmiące pg_fastsearch, zmyślony agregat). Zweryfikuj wszystko nieznane w dokumentacji Postgresa, zanim to uruchomisz.
• SQL sklejany ze stringów. Wygenerowane buildery zapytań czasem konkatenują dane wejściowe użytkownika prosto w SQL. Każda wartość musi być parametryzowana — odrzucaj wszystko, co interpoluje się do treści zapytania.
• Ignorowanie wydajności zapisu. Schemat strojony wyłącznie pod odczyty (ciężka denormalizacja, mnóstwo indeksów) może okaleczyć ścieżkę zapisu. Powiedz AI swój stosunek odczytów do zapisów, by zrównoważyło oba.

Co dalej

• Wzorce API — idempotentne endpointy, paginacja kursorem i generowanie OpenAPI na bazie tego schematu.
• Wzorce serverless do uruchamiania tych baz danych w środowiskach chmurowych i edge.