Compétences Database Architect
🏛️

Database Architect

Sûr

Concevoir des architectures de base de données évolutives

Choisir la mauvaise base de données ou une mauvaise conception de schéma entraîne des reprises coûteuses et des problèmes de performances. Cette compétence fournit des conseils d'experts sur le choix de la technologie de base de données, la modélisation des données et la conception d'architecture pour construire des couches de données évolutives dès le départ.

Prend en charge: Claude Codex Code(CC)
🥉 72 Bronze
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "Database Architect". Concevoir un schéma pour une plateforme de blog avec utilisateurs, articles, commentaires et étiquettes.

Résultat attendu:

Le schéma recommandé inclut : table utilisateurs (id, email, created_at), table articles avec clé étrangère vers utilisateurs, table commentaires avec parent_id auto-référentiel pour les fils de discussion, table étiquettes avec table de junction plusieurs-à-plusieurs post_tags. Index sur articles.user_id, commentaires.article_id, et index de texte intégral sur articles.titre et contenu.

Utilisation de "Database Architect". Dois-je utiliser Redis ou PostgreSQL pour le stockage de sessions ?

Résultat attendu:

Utilisez Redis pour le stockage de sessions lorsque vous avez besoin d'un accès rapide, d'une expiration automatique via TTL et d'une évolutivité horizontale. Utilisez PostgreSQL lorsque les sessions doivent survivre aux redémarrages Redis, nécessitent des requêtes complexes ou doivent participer aux transactions de base de données. Pour la plupart des applications web, Redis avec persistance PostgreSQL offre le meilleur équilibre.

Audit de sécurité

Sûr
v1 • 2/24/2026

Static analysis scanned 0 files with risk score 0/100. Evaluation confirms this is a prompt-only skill with no executable code. The skill provides database architecture guidance through instructional text only. No dangerous patterns, network access, or code execution vectors detected. Safe for publication.

0
Fichiers analysés
0
Lignes analysées
0
résultats
1
Total des audits
Aucun problème de sécurité trouvé
Audité par: claude

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
50
Communauté
100
Sécurité
74
Conformité aux spécifications

Ce que vous pouvez construire

Conception de plateforme Greenfield

Concevoir une architecture de base de données complète pour une nouvelle plateforme SaaS, incluant le choix de la technologie, la conception du schéma et la stratégie de mise à l'échelle.

Planification de migration de base de données

Créer un plan de migration détaillé pour passer d'une base de données MySQL monolithique à une architecture de microservices avec persistance polyglotte.

Conception de schéma NoSQL

Concevoir des schémas de documents et des modèles d'accès pour un tableau de bord analytique à haute vélocité utilisant MongoDB ou DynamoDB.

Essayez ces prompts

Choix de technologie de base 
Je construis une nouvelle application qui doit stocker des profils utilisateur, des transactions et des journaux d'activité. L'application s'attend à 10 000 utilisateurs actifs quotidiens au départ. Aidez-moi à choisir la bonne technologie de base de données et expliquez les compromis.
Demande de conception de schéma 
Concevoir un schéma de base de données pour un outil de gestion de projet multi-locataires. Chaque locataire a des utilisateurs, des projets, des tâches et des commentaires. Montrez les tables, les relations et les index clés nécessaires.
Planification de stratégie de migration 
Nous devons migrer d'une seule instance MySQL vers une architecture partitionnée supportant 100 millions d'enregistrements ou plus. Créez un plan de migration sans temps d'arrêt avec des phases, des procédures de retour en arrière et des critères de réussite.
Architecture CQRS avancée 
Concevoir une architecture CQRS avec source d'événements pour un système de gestion de commandes. Incluez la conception du magasin d'événements, les projections du modèle de lecture, les stratégies d'instantanés et la gestion de l'évolution du schéma au fil du temps.

Bonnes pratiques

  • Toujours comprendre les modèles d'accès et les exigences d'échelle avant de sélectionner la technologie de base de données
  • Commencer normalisé, puis dénormaliser sélectivement en fonction des performances de requête mesurées
  • Planifier les migrations avec des procédures automatisées de retour en arrière et tester minutieusement en préproduction

Éviter

  • Choisir des bases de données à la mode sans comprendre la complexité opérationnelle
  • Sur-normaliser les charges de travail intensives en lecture causant des opérations JOIN excessives
  • Omettre la planification des sauvegardes et des retours en arrière avant les migrations en production

Foire aux questions

Quelle base de données dois-je choisir pour ma startup ?
Commencez avec PostgreSQL pour la plupart des applications. Il gère bien les données relationnelles, prend en charge JSON pour la flexibilité et s'étend à des millions d'utilisateurs. Passez aux bases de données spécialisées uniquement lorsque vous avez des besoins spécifiques comme les données de séries temporelles, les relations de graphe ou un débit d'écriture massif.
Comment savoir quand partitionner ma base de données ?
Envisagez le partitionnement lorsque la mise à l'échelle verticale devient trop coûteuse, que le débit d'écriture dépasse la capacité d'un seul nœud, ou que le volume des données impacte les fenêtres de sauvegarde et de maintenance. Optimisez d'abord avec des répliques de lecture, du cache et l'optimisation des requêtes avant de partitionner.
Dois-je utiliser un ORM ou écrire du SQL brut ?
Utilisez des ORM comme Prisma ou SQLAlchemy pour les opérations CRUD et la sécurité des types. Écrivez du SQL brut pour les requêtes analytiques complexes, les opérations en bloc, ou lorsque l'ORM génère des requêtes inefficaces. De nombreuses équipes utilisent les deux : ORM pour les opérations standard et SQL brut pour les chemins critiques en performance.
Comment concevoir pour la multi-location ?
Trois approches existent : schéma partagé avec colonne tenant_id (le plus simple), schéma séparé par locataire (meilleure isolation), ou base de données séparée par locataire (isolation maximale). Commencez avec schéma partagé et tenant_id. Passez à des schémas ou bases de données séparés pour les exigences de conformité ou les clients entreprises de haute valeur.
Quelle stratégie d'indexation dois-je utiliser ?
Indexez les colonnes utilisées dans les clauses WHERE, les conditions JOIN et les instructions ORDER BY. Utilisez des index composites pour les requêtes multi-colonnes avec la colonne la plus sélective en premier. Surveillez les journaux de requêtes lentes pour identifier les index manquants. Évitez la sur-indexation des tables à forte écriture car chaque index ajoute une surcharge d'écriture.
Comment puis-je migrer sans temps d'arrêt ?
Utilisez le modèle expansion-contraction : d'abord ajouter le nouveau schéma à côté de l'ancien (expansion), migrer les données de manière incrémentale avec des écritures doubles, vérifier la cohérence, basculer les lectures vers le nouveau schéma, puis supprimer l'ancien schéma (contraction). Ayez toujours des procédures de retour en arrière et testez la migration complète en préproduction.

Détails du développeur

Auteur

sickn33

Licence

MIT

Dépôt

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/database-architect

Réf

main

Structure de fichiers

📄 SKILL.md