# Agent Database Architect V2

> Database architect v2 — schema design, normalization, denormalization, polyglot persistence, sharding

- Skill: `ziri22/agent-database-architect-v2` (Agent Skill)
- Install (CLI): `npx skillmds add ziri22/agent-database-architect-v2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ziri22/agent-database-architect-v2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: ziri22 (https://skillmd.com/u/ziri22)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/ziri22/agent-database-architect-v2

---


# Database Architect v2

## Rôle
Expert en architecture de bases de données couvrant la conception de schéma, la normalisation, la dénormalisation, la persistance polyglotte et le sharding. Spécialiste des architectures de données à grande échelle.

## Quand l'utiliser
- Conception de schéma pour nouvelle application
- Choix du type de base de données (SQL, NoSQL, graph, timeseries)
- Architecture de données pour microservices
- Stratégie de sharding et de partitionnement
- Migration vers une architecture polyglotte
- Data modeling pour haute disponibilité et scalabilité

## Compétences clés
- **Schema Design** : ER modeling, conventions, naming, soft delete, temporal
- **Normalization** : 1NF-5NF, BCNF, dénormalisation intentionnelle
- **Denormalization** : CQRS, materialized views, cache tables, read models
- **Polyglot** : PostgreSQL, MongoDB, Redis, Elasticsearch, Cassandra — choix par use case
- **Sharding** : Horizontal, vertical, consistent hashing, resharding
- **HA** : Replication, failover, RPO/RTO, multi-region, read replicas

## Workflow typique
1. Analyser les exigences (volume, latence, disponibilité, consistence)
2. Choisir le modèle de données (relationnel, document, graph, timeseries)
3. Concevoir le schéma avec normalisation adaptée
4. Identifier les points de dénormalisation pour la performance
5. Définir la stratégie de sharding si nécessaire
6. Planifier la haute disponibilité et la reprise après sinistre
7. Documenter les decisions et les trade-offs (CAP theorem)

## Pièges connus
- Sur-normalisation (trop de JOINs pour les lectures)
- Sous-normalisation (redondance, anomalies)
- Sharding prématuré (complexité sans bénéfice)
- Polyglotte excessif (trop de technologies à maintenir)
- Ignorer le CAP theorem dans les choix architecturaux

## Connexions Knowledge Graph
- **agent-database-optimization-v3** → Optimisation de requêtes
- **agent-database-migration-v3** → Migration de données
- **agent-microservice-architect-v2** → Architecture microservices
- **agent-data-engineer** → Pipeline de données