Wzorce i strategie NoSQL

Modelowanie danych NoSQL z Claude Code, Codeksem lub Cursorem działa wtedy, gdy agent projektuje na podstawie spisanej listy wzorców dostępu, czyta żywy schemat przez serwer MCP MongoDB lub Neo4j w trybie tylko do odczytu i oddaje mapę wzorców dostępu oraz testy dowodzące, że każde zapytanie korzysta z indeksu. Schemat NoSQL bez tych dowodów to zgadywanie.

Ta strona jest dla programistów, którzy pozwalają agentowi projektować albo zmieniać model danych: dokumentowy, klucz-wartość, grafowy lub wektorowy. Awaria, której zapobiega, wygląda tak: schemat MongoDB był czysty na demie, jeden dokument user z osadzonymi zamówieniami, adresami i koszykiem. Pół roku później tablica zamówień ma 4000 wpisów, dokument zbliża się do limitu 16 MB w MongoDB, a każdy odczyt profilu ciągnie całość przez sieć. Agent, który napisał ten schemat, nigdy nie widział twoich wzorców dostępu, więc zoptymalizował go pod demo.

W NoSQL nie ma schematu relacyjnego, za którym można się schować. Model danych jest projektem, a błędna decyzja „osadzić czy referencjonować” albo zły klucz partycji kosztuje sporo, gdy pojawi się ruch. Poniższe przepisy każą agentowi uzasadnić każdą decyzję, a potem udowodnić ją na prawdziwym silniku. Ty przeglądasz tabelę i raport z testów, a nie każde zapytanie.

Co wyniesiesz z tych przepisów NoSQL

• Konfigurację MCP tylko do odczytu dla MongoDB i Neo4j w Claude Code, Codeksie i Cursorze, z flagą, dzięki której MongoDB odrzuca skany kolekcji
• Prompt „osadzić czy referencjonować”, który zmusza agenta do argumentowania wzorcami dostępu i granicami wzrostu
• Prompt do agregacji, w którym plan explain jest częścią wyniku
• Prompt do projektu jednej tabeli DynamoDB, który przypisuje każdemu wzorcowi dostępu warunek klucza albo GSI
• Prompty do Neo4j 5 i Atlas Vector Search, które omijają usuniętą składnię, wciąż generowaną przez agentów
• Zestaw testów wzorców dostępu, pisany przez agenta i uruchamiany w CI, żeby nikt nie musiał czytać każdego zapytania

Jak działa pętla przepisów NoSQL?

Każdy magazyn danych przechodzi te same cztery kroki. Zmienia się silnik, pętla zostaje.

1. Najpierw spisz wzorce dostępu. Numerowaną listę odczytów i zapisów, których potrzebuje funkcja, z przybliżoną częstotliwością. Ta lista jest specyfikacją i to ją zatwierdzasz.
2. Każ agentowi oddać projekt jako artefakt. Tabelę, która każdemu wzorcowi dostępu przypisuje kształt dokumentu, warunek klucza albo indeks, a nie akapit prozy.
3. Sprawdź na prawdziwym silniku. Agent czyta prawdziwy schemat i uruchamia explain przez MCP albo pracuje na DynamoDB Local, zamiast zgadywać nazwy pól.
4. Utrwal to testami. Jeden test na wzorzec dostępu sprawdza wynik i plan (użyty indeks, brak skanu). CI uruchamia je przy każdej zmianie.

Krok 1: podłącz agenta do prawdziwego schematu

Bez połączenia z bazą agent wymyśla nazwy kolekcji i pól. Z połączeniem najpierw pobiera przykładowy dokument, widzi, że już zapisujesz customerId, a nie userId, i trzyma się twojej konwencji. Ogólną konfigurację, role tylko do odczytu i serwery dla innych baz opisuje strona o serwerach MCP dla baz danych; ten krok to część specyficzna dla NoSQL.

Tę stronę obsługują dwa serwery, oba zweryfikowane 2026-09-26:

• MongoDB MCP Server (npm mongodb-mcp-server 3.0.4, oficjalny). Narzędzia to m.in. collection-schema, collection-indexes, find, aggregate i explain. --readOnly usuwa narzędzia do tworzenia, aktualizacji i usuwania. --indexCheck odrzuca każde zapytanie, które skanowałoby całą kolekcję, więc „użyj indeksu” przestaje być radą i staje się twardym błędem, który agent musi naprawić.
• Neo4j Cypher MCP server (PyPI mcp-neo4j-cypher 0.6.0, z neo4j-contrib). Narzędzia to get_neo4j_schema (wymaga wtyczki APOC), read_neo4j_cypher i write_neo4j_cypher; --read-only usuwa narzędzie zapisu. To pakiet Pythona, więc uruchamiasz go przez uvx, nie npx.

Serwery działają tak samo we wszystkich trzech narzędziach; różni się tylko miejsce konfiguracji.

Claude Code

Uruchom w terminalu w katalogu głównym repozytorium. -s project zapisuje .mcp.json, a ujęte w apostrofy ${NEO4J_PASSWORD} jest rozwijane z twojej powłoki przy starcie serwera, więc sekret nie trafia do pliku:

claude mcp add -s project mongodb \
  -e MDB_MCP_CONNECTION_STRING=mongodb://localhost:27017/shop \
  -- npx -y mongodb-mcp-server@3.0.4 --readOnly --indexCheck

claude mcp add -s project neo4j \
  -e NEO4J_URI=bolt://localhost:7687 -e NEO4J_USERNAME=neo4j \
  -e 'NEO4J_PASSWORD=${NEO4J_PASSWORD}' \
  -- uvx mcp-neo4j-cypher@0.6.0 --read-only

Codex

Uruchom w terminalu. codex mcp add zapisuje wpis w ~/.codex/config.toml:

codex mcp add mongodb \
  --env MDB_MCP_CONNECTION_STRING=mongodb://localhost:27017/shop \
  -- npx -y mongodb-mcp-server@3.0.4 --readOnly --indexCheck

codex mcp add neo4j \
  --env NEO4J_URI=bolt://localhost:7687 --env NEO4J_USERNAME=neo4j \
  --env NEO4J_PASSWORD="$NEO4J_PASSWORD" \
  -- uvx mcp-neo4j-cypher@0.6.0 --read-only

Powstałe wpisy, które możesz też napisać ręcznie:

[mcp_servers.mongodb]
command = "npx"
args = ["-y", "mongodb-mcp-server@3.0.4", "--readOnly", "--indexCheck"]

[mcp_servers.mongodb.env]
MDB_MCP_CONNECTION_STRING = "mongodb://localhost:27017/shop"

[mcp_servers.neo4j]
command = "uvx"
args = ["mcp-neo4j-cypher@0.6.0", "--read-only"]

[mcp_servers.neo4j.env]
NEO4J_URI = "bolt://localhost:7687"
NEO4J_USERNAME = "neo4j"
NEO4J_PASSWORD = "your-local-password"

Powłoka rozwija "$NEO4J_PASSWORD" jeden raz, przy uruchomieniu codex mcp add, więc hasło zostaje zapisane dosłownie w ~/.codex/config.toml. Ten plik należy do użytkownika i leży poza repozytorium; niech tak zostanie. codex mcp get mongodb wypisuje sparsowany wpis z zamaskowanym connection stringiem.

Cursor

Dodaj do ~/.cursor/mcp.json (poziom użytkownika, poza repozytorium). Wpis Neo4j zawiera hasło zapisane dosłownie, więc nigdy nie umieszczaj go w projektowym .cursor/mcp.json, który trafia do commita. Wpis MongoDB bez danych uwierzytelniających, taki jak lokalny poniżej, może zostać w pliku projektu:

{
  "mcpServers": {
    "mongodb": {
      "command": "npx",
      "args": ["-y", "mongodb-mcp-server@3.0.4", "--readOnly", "--indexCheck"],
      "env": { "MDB_MCP_CONNECTION_STRING": "mongodb://localhost:27017/shop" }
    },
    "neo4j": {
      "command": "uvx",
      "args": ["mcp-neo4j-cypher@0.6.0", "--read-only"],
      "env": {
        "NEO4J_URI": "bolt://localhost:7687",
        "NEO4J_USERNAME": "neo4j",
        "NEO4J_PASSWORD": "your-local-password"
      }
    }
  }
}

Tylko do odczytu na wszystkim, co współdzielone

Trzymaj --readOnly i --read-only na każdym połączeniu ze stagingiem i produkcją. Z tymi flagami agent nie utworzy też indeksu i właśnie o to chodzi: zapisuje indeks w pliku migracji, który przechodzi przegląd i CI (zobacz wzorce migracji baz danych). Zdejmij flagę tylko na lokalnej, jednorazowej bazie z realistycznymi danymi, gdzie agent może tworzyć i usuwać indeksy w trakcie iteracji. README MongoDB zaleca zmienną środowiskową zamiast --connectionString, bo argumenty wiersza poleceń widać na liście procesów.

Krok 2: zdecyduj „osadzić czy referencjonować” na podstawie wzorców dostępu

Najważniejsza decyzja w bazie dokumentowej to, czy powiązane dane osadzić, czy trzymać przez referencję. Agent podejmuje ją dobrze, gdy dostaje wzorce dostępu, wzorzec zapisów i granice wzrostu, a nie prośbę o „dobry schemat”.

Prompt do skopiowania: osadzić czy referencjonować w modelu zamówienia

Design the MongoDB data model for an e-commerce Order. First read the existing
`orders` and `customers` collections through the MongoDB MCP server
(collection-schema, collection-indexes) and follow their field names.

Access patterns, in priority order:
1. Load one order with all line items for the order-detail page (95% of reads).
2. List a customer's last 20 orders, summary fields only, newest first.
3. Daily revenue by product category (a nightly job).
Writes: line items are immutable once the order is placed; status changes about
3 times per order.

Deliver:
- A table: access pattern -> document shape or collection -> index that serves it.
- For line items and for the customer reference, decide embed vs reference and
  name the rule you applied (bounded vs unbounded growth, read-together,
  atomicity, update frequency).
- The exact createIndex calls, following equality-sort-range order, and say which
  patterns (if any) can be covered queries.
- A $jsonSchema validator for the collection.
- Flag any array that can grow without bound toward the 16 MB document limit.
Do not create anything; write the indexes and validator into a migration file.

Dobra odpowiedź osadza pozycje zamówienia (ograniczone, niezmienne, zawsze czytane razem), zapisuje migawkę customer: { id, name } zamiast robić $lookup przy każdym odczycie i obsługuje wzorzec 2 indeksem złożonym { customerId: 1, createdAt: -1 }. Wzorzec 1 zwraca cały dokument, więc nie może być zapytaniem pokrytym (covered query). Jeśli agent twierdzi inaczej, nie przemyślał projekcji — odeślij mu to do poprawki. Tabela wzorców dostępu to artefakt, który zatwierdzasz. Kod z niej wynika.

Krok 3: każ każdej agregacji udowodnić swój indeks

Potoki agregacji to miejsce, w którym agent oszczędza najwięcej czasu, i zarazem to, gdzie najczęściej oddaje zapytanie zwracające poprawny wynik przy skanie całej kolekcji. Plan wykonania musi być częścią wyniku.

Prompt do skopiowania: potok agregacji z dowodem planu

Write a MongoDB aggregation on `orders` that returns monthly revenue by product
category for the trailing 12 months, active products only, sorted by revenue
descending. Check the schema through the MongoDB MCP server first; if a
denormalized `category` field exists on the order line, do not use $lookup.

Then run the pipeline through the MCP `explain` tool with executionStats.
Report: the winning plan's first stage (IXSCAN or COLLSCAN), totalDocsExamined,
totalKeysExamined, and nReturned. If the first $match does not use an index,
propose the index in the migration file and explain why its key order fits the
$match and $sort. Stop and ask me if the only fix is a schema change.

Ponieważ serwer działa z --indexCheck, potok, którego pierwszy $match skanuje kolekcję, kończy się błędem, zamiast zwrócić wiarygodnie wyglądającą odpowiedź. Agent widzi błąd, proponuje indeks, a na lokalnej bazie (gdzie zdjąłeś --readOnly) tworzy go i ponawia explain, aż plan zacznie się od IXSCAN. Liczba, którą czytasz, to stosunek totalDocsExamined do nReturned: bliski 1 jest zdrowy, setki do jednego oznaczają indeks o złym kształcie.

Krok 4: zaprojektuj schemat DynamoDB w jednej tabeli

DynamoDB najmocniej karze za mgliste prompty. Klucz partycji o niskiej kardynalności tworzy gorącą partycję, która dławi się pod obciążeniem, a pominięty wzorzec dostępu oznacza Scan na produkcji. Nie ma tu schematu tylko do odczytu, który można by podejrzeć, więc agent pracuje z listy i dowodzi projektu na DynamoDB Local (obraz Dockera amazon/dynamodb-local).

Prompt do skopiowania: projekt jednej tabeli DynamoDB

Design a single-table DynamoDB schema for a multi-tenant SaaS with Organizations,
Users, Projects, and Tasks. Access patterns I must serve:
1. Get an org and all its users.
2. Get a user by email for login.
3. List tasks assigned to a user across projects, sorted by due date.
4. List a project's open tasks.

Deliver a table: access pattern -> table or GSI -> key condition. Use one
overloaded PK/SK plus the minimum number of GSIs; justify each GSI and give its
projection (KEYS_ONLY, INCLUDE with named attributes, or ALL) with the write-cost
trade-off. Flag any pattern that can create a hot partition and propose write
sharding. Use AWS SDK for JavaScript v3 (@aws-sdk/lib-dynamodb) only. Every
access pattern must be a Query or GetItem; a Scan is a design failure.
Write one test per pattern against DynamoDB Local.

Część wykonywalna jest niewielka. Oto zapytanie dla wzorca 3 w AWS SDK v3 (@aws-sdk/lib-dynamodb 3.1141.0 w npm, 2026-09-26); łańcuch .query(params).promise() z v2 tu nie działa:

import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
import { DynamoDBDocumentClient, QueryCommand } from '@aws-sdk/lib-dynamodb';

const ddb = DynamoDBDocumentClient.from(new DynamoDBClient({}));

// GSI1: GSI1PK = USER#<id>, GSI1SK = TASK#<dueDate>#<taskId>
export async function getUserTasks(userId, fromDate) {
  const { Items } = await ddb.send(
    new QueryCommand({
      TableName: 'SaaSPlatform',
      IndexName: 'GSI1',
      KeyConditionExpression: 'GSI1PK = :pk AND GSI1SK >= :start',
      ExpressionAttributeValues: {
        ':pk': `USER#${userId}`,
        ':start': `TASK#${fromDate}`,
      },
      ScanIndexForward: true, // ascending by due date
    }),
  );
  return Items;
}

Zapisy wsadowe używają BatchWriteCommand, który nadal przyjmuje najwyżej 25 elementów na żądanie.

Krok 5: zamodeluj graf w składni Neo4j 5

Przy mocno powiązanych danych (grafy społecznościowe, rekomendacje, siatki oszustów) poproś najpierw o model węzłów i relacji, a dopiero potem o Cypher. Wymagaj składni Neo4j 5: dane treningowe są pełne formy ograniczeń z Neo4j 4, CREATE CONSTRAINT ON ... ASSERT, którą Neo4j 5 odrzuca.

Prompt do skopiowania: model grafu i zapytanie rekomendacyjne

Read the current graph through the Neo4j MCP server (get_neo4j_schema) and keep
its labels and relationship types. Model User, Post, and Tag nodes with FRIENDS,
POSTED, LIKED, VIEWED, and TAGGED_WITH relationships, with timestamps where they
matter. Then write a query: posts my friends liked in the last 7 days that I have
not viewed, ranked by the number of distinct friends who liked each one.

Neo4j 5 syntax only: constraints use CREATE CONSTRAINT ... FOR (n:Label) REQUIRE
n.prop IS UNIQUE, and negative patterns use NOT EXISTS { ... }. Run EXPLAIN on
every query through read_neo4j_cypher and report whether the plan starts from a
NodeUniqueIndexSeek or an AllNodesScan. Cap the friend fan-out if a user can have
more than 5,000 FRIENDS relationships.

Tak wygląda poprawna odpowiedź:

CREATE CONSTRAINT user_id IF NOT EXISTS
FOR (u:User) REQUIRE u.id IS UNIQUE;

CREATE CONSTRAINT post_id IF NOT EXISTS
FOR (p:Post) REQUIRE p.id IS UNIQUE;

// Posts friends liked in the last 7 days that this user has not viewed
MATCH (user:User {id: $userId})-[:FRIENDS]-(friend:User)-[l:LIKED]->(post:Post)
WHERE l.at > datetime() - duration('P7D')
  AND NOT EXISTS { (user)-[:VIEWED]->(post) }
WITH post, count(DISTINCT friend) AS friendLikes
RETURN post.id, post.content, friendLikes
ORDER BY friendLikes DESC
LIMIT 10;

Ograniczenie user_id daje zapytaniu punkt startowy: EXPLAIN powinien pokazać NodeUniqueIndexSeek na :User(id). AllNodesScan oznacza brak ograniczenia albo literówkę w etykiecie.

Krok 6: dodaj wyszukiwanie wektorowe w MongoDB Atlas

Embeddingi zapisane obok dokumentów dają wyszukiwanie semantyczne bez osobnej bazy wektorowej. W MongoDB Atlas odpytujesz je etapem agregacji $vectorSearch na indeksie typu vectorSearch. Starsze mapowanie pola knnVector należy do Atlas Search, jest przestarzałe i nie obsługuje $vectorSearch, a agenci wciąż je generują.

from pymongo.operations import SearchIndexModel

# A vectorSearch index needs SearchIndexModel(type="vectorSearch").
# A plain-dict create_search_index() call creates an Atlas Search index instead.
db.products.create_search_index(
    model=SearchIndexModel(
        definition={
            "fields": [
                {"type": "vector", "path": "text_embedding",
                 "numDimensions": 384, "similarity": "cosine"},
                {"type": "filter", "path": "price"},
                {"type": "filter", "path": "categories"},
            ]
        },
        name="product_embeddings",
        type="vectorSearch",
    )
)

pipeline = [
    {"$vectorSearch": {
        "index": "product_embeddings",
        "path": "text_embedding",
        "queryVector": query_embedding,  # 384 floats from the same model
        "numCandidates": 200,
        "limit": 10,
        "filter": {"price": {"$lte": 100}},
    }},
    {"$addFields": {"score": {"$meta": "vectorSearchScore"}}},
    {"$project": {"text_embedding": 0}},
]

Prompt do skopiowania: indeks wektorowy i kontrola trafności

My Atlas collection `products` stores a `text_embedding` field and I query it with
$vectorSearch. Read a sample document through the MongoDB MCP server and report
the embedding length. Generate the index with the vectorSearch index type: a
`fields` array with {type: "vector", path, numDimensions, similarity} plus filter
entries for `price` and `categories`. Create it in PyMongo with
SearchIndexModel(type="vectorSearch"), never the knnVector mapping. Then write a
test with 20 golden queries and their expected product ids that fails if recall@10
drops below the value we record today, and a test that fails if any stored
embedding length differs from numDimensions.

Jak zweryfikować projekt NoSQL bez czytania każdego zapytania?

Zatwierdzasz dwie rzeczy: tabelę wzorców dostępu z kroku projektowego i raport z testów. Nie czytasz każdego potoku, warunku klucza ani zapytania Cypher, bo testy przy każdym przebiegu CI sprawdzają na prawdziwym silniku to, czego szukałby recenzent. To ta sama zmiana, którą opisuje strona o czytaniu dowodów zamiast kodu.

Magazyn	Co sprawdza test	Kiedy test nie przechodzi
MongoDB	Każdy wzorzec dostępu zwraca właściwe dokumenty, a wynik explain nie zawiera COLLSCAN	Brakujący albo źle uporządkowany indeks
MongoDB	Walidator $jsonSchema odrzuca dokument bez wymaganego pola	Kształt rozminął się z zatwierdzonym projektem
DynamoDB	Każdy wzorzec obsługuje Query albo GetItem; middleware rzuca wyjątek przy każdym ScanCommand	Wzorzec dostępu, którego projekt kluczy nie pokrywa
Neo4j	EXPLAIN każdego zapytania nie zawiera AllNodesScan; SHOW CONSTRAINTS wymienia każdy klucz unikalny	Usunięte ograniczenie albo literówka w etykiecie
Wektory	recall@10 na złotych zapytaniach nie spada poniżej zapisanej wartości bazowej; długość każdego embeddingu równa się numDimensions	Zmiana modelu bez ponownego wygenerowania embeddingów

Asercja na planie sprawdza cały plan, więc działa zarówno dla planu find, jak i dla planu agregacji:

const plan = await db.collection('orders').aggregate(pipeline).explain('executionStats');
expect(JSON.stringify(plan)).not.toContain('COLLSCAN');

Uruchamiaj te testy w CI na prawdziwym silniku: kontener MongoDB przez Testcontainers (@testcontainers/mongodb 12.1.0 w npm, 2026-09-26), DynamoDB Local i kontener Neo4j. Zamockowany sterownik nie wygeneruje planu zapytania, więc niczego tu nie dowodzi. Szerszą konfigurację opisują wzorce testowania integracyjnego, a zasilanie bazy realistyczną ilością danych strategie danych testowych.

Prompt do skopiowania: zestaw testów wzorców dostępu

Write one integration test per access pattern in docs/data-model.md. Run them
against a real engine started by the test setup (Testcontainers for MongoDB and
Neo4j, DynamoDB Local for DynamoDB), seeded with at least 10,000 documents or
items so the query planner behaves as it does in production.
Each test asserts the returned data AND the plan:
- MongoDB: explain('executionStats') contains no COLLSCAN.
- DynamoDB: register client middleware that throws on ScanCommand.
- Neo4j: EXPLAIN contains no AllNodesScan.
Add one negative test per collection proving the $jsonSchema validator rejects a
document without its required fields. Run the suite, paste the summary, and do
not weaken an assertion to make a test pass; stop and tell me instead.

Kto zatwierdza: programista odpowiedzialny za funkcję akceptuje tabelę wzorców dostępu, zanim powstanie jakikolwiek kod, a CI musi być zielone przed merge’em. Recenzent czyta tabelę, nazwy testów i raport. Jeśli agent zmienia asercję zamiast zapytania, traktuj to jako nieudaną zmianę, tak jak opisuje to strona o ochronie wyroczni testowej.

Kiedy modele danych NoSQL się psują

• Tablica rośnie bez ograniczeń w stronę limitu 16 MB. Objaw: odczyty profilu z miesiąca na miesiąc zwalniają, potem zapisy kończą się błędem. Naprawa: przenieś tablicę do kolekcji podrzędnej kluczowanej identyfikatorem rodzica (albo podziel ją na kubełki miesięczne), uzupełnij dane migracją i dopisz pytanie o nieograniczony wzrost do promptu projektowego, żeby następny model to uwzględnił.
• Gorąca partycja w DynamoDB. Klucz typu TENANT#<id> zaczyna być dławiony, gdy ruch jednego najemcy przekroczy limit przepustowości pojedynczej partycji, a dodatkowa przydzielona przepustowość tego limitu nie podnosi. Naprawa: dodaj sufiks sharda (TENANT#<id>#<0-9>), zapisuj do losowego sharda i przy odczycie zbieraj wyniki ze wszystkich (scatter-gather).
• Projekcja GSI pomija atrybut. Zapytania do indeksu zwracają elementy bez tego pola, a kod czyta undefined. Projekcji GSI nie da się zmienić po utworzeniu. Naprawa: utwórz nowy GSI z właściwą projekcją, przełącz odczyty, potem usuń stary.
• Superwęzeł w Neo4j. Użytkownik z milionami relacji FRIENDS zamienia każde przejście grafu od niego w skan. Naprawa: ogranicz rozgałęzienie w zapytaniu (WITH friend LIMIT 1000) albo zamodeluj gorącą relację jako osobny węzeł.
• Nieaktualne embeddingi. Wyniki wektorowe po cichu się pogarszają, gdy zmieniasz model embeddingów, a istniejących dokumentów nie przeliczasz. Naprawa: test wymiaru wyłapie zmianę długości; przy zamianie na model o tej samej długości przelicz wszystko i w tej samej zmianie zapisz nową wartość bazową recall.
• Agent wymyśla schemat. Zapytania odwołują się do pól, których nie masz. Naprawa: sprawdź, czy serwer MCP jest podłączony (/mcp w Claude Code, codex mcp list w Codeksie), i każ agentowi wywołać collection-schema albo get_neo4j_schema, zanim cokolwiek napisze.
• Agent próbuje zapisać przez MCP. Z --readOnly narzędzia zapisu nie istnieją, więc próba kończy się niegroźnym błędem. Naprawa: zostaw flagę i przeprowadź zmianę migracją; nigdy nie zdejmuj jej, żeby obejść błąd. Szerszy model zagrożeń opisuje strona o zabezpieczaniu serwerów MCP.

Dokąd dalej z modelowaniem danych NoSQL

• Przepisy bazodanowe: hub wszystkich czterech stron z przepisami bazodanowymi
• Serwery MCP dla baz danych: role tylko do odczytu i konfiguracja dla Postgresa, Supabase, Neona i MongoDB
• Wzorce migracji baz danych: jak przeprowadzić indeksy i walidatory z tej strony przez przegląd i CI
• Wzorce optymalizacji SQL: kiedy model relacyjny jest lepszym wyborem
• Najlepsze praktyki ORM: typowany dostęp do danych z Prismą i TypeORM