Database architect v2 — schema design, normalization, denormalization, polyglot persistence, sharding
Scanned 9/10/2026
Install to Claude Code
npx -y skills add ziri22/agency-roster --skill agent-database-architect-v2 --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Agent Database Architect V2?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/ziri22-agent-database-architect-v2)More formats (shields.io, HTML) on the badges page.
---
name: agent-database-architect-v2
description: Database architect v2 — schema design, normalization, denormalization, polyglot persistence, sharding
author: "Ziri Yahi"
tags:
- database
- architecture
- schema
- normalization
- polyglot
- sharding
---
# 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éesIs this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!