Progettista di Schemi Database
Il Progettista di Schemi Database trasforma una descrizione in linguaggio naturale dei requisiti dati della tua applicazione in uno schema database completo e normalizzato, con relazioni corrette, vincoli, indici e SQL pronto per la migrazione. Gestisce la traduzione da "ciò che il business necessita" a "come il database deve essere strutturato", così parti da una base solida invece di dover rifattorizzare in seguito.
Sviluppatori backend, full-stack engineer e tech lead usano questo template all'inizio di nuovi progetti, quando aggiungono funzionalità importanti che richiedono nuovi modelli dati, o quando ristrutturano un database cresciuto organicamente senza un design chiaro. È particolarmente utile per sviluppatori che conoscono SQL ma vogliono un secondo parere su decisioni di normalizzazione, modellazione delle relazioni e strategia degli indici.
Il prompt richiede di descrivere i dati in termini di business (entità, attributi e relazioni) invece di passare direttamente alle definizioni delle tabelle. Questo ti costringe a pensare prima al modello di dominio, approccio che produce costantemente schemi migliori rispetto alla traduzione diretta di un wireframe in tabelle. L'output include non solo le istruzioni CREATE TABLE ma anche il ragionamento dietro le scelte di normalizzazione e selezione degli indici, così puoi valutare i compromessi prima di impegnarti con una struttura.
This prompt is just the starting point
Score it with AI, optimize it with one click, track versions, and build your prompt library.
The Prompt
Progetta uno schema database basato sui seguenti requisiti applicativi: **Motore di Database**: [PostgreSQL / MySQL / SQL Server / SQLite] **Descrizione dell'Applicazione**: [BREVE DESCRIZIONE DI COSA FA L'APP, es. "Uno strumento di project management dove i team creano progetti, assegnano task ai membri, tracciano il tempo impiegato e generano report settimanali"] **Entità Principali e Relativi Attributi**: [ELENCA OGNI ENTITÀ CON I SUOI ATTRIBUTI CHIAVE. Per esempio: - Utente: nome, email, ruolo (admin/membro/visualizzatore), data di creazione - Progetto: nome, descrizione, stato (attivo/archiviato), proprietario (un utente), scadenza - Task: titolo, descrizione, stato (da fare/in corso/completato), assegnatario (un utente), progetto, priorità (bassa/media/alta/urgente), data di scadenza, ore stimate - Registrazione Tempo: task, utente, ore registrate, data, note] **Relazioni Chiave e Regole**: [DESCRIVI LE REGOLE DI BUSINESS. Per esempio: - Un utente può appartenere a più progetti - Ogni task appartiene a esattamente un progetto - Un task può avere un solo assegnatario alla volta, ma la cronologia delle riassegnazioni deve essere tracciata - L'eliminazione di un progetto non deve eliminare le registrazioni tempo (servono per la fatturazione)] **Scala Prevista**: [NUMERI APPROSSIMATIVI, es. "~500 utenti, ~200 progetti attivi, ~10.000 task, ~50.000 registrazioni tempo, crescita del 20% mensile"] **Requisiti Speciali**: [EVENTUALI VINCOLI, es. "Deve supportare soft delete", "Serve ricerca full-text sui titoli dei task", "Multi-tenant con row-level security", "Audit trail per tutte le modifiche"] Fornisci il design dello schema con questa struttura: 1. **Sommario Entità-Relazioni**: Una descrizione testuale di tutte le entità e le loro relazioni (uno-a-uno, uno-a-molti, molti-a-molti), incluse le tabelle di join necessarie per le relazioni molti-a-molti. 2. **Note sulla Normalizzazione**: Spiega le decisioni di normalizzazione. Se hai denormalizzato qualcosa per motivi di performance, spiega perché e qual è il compromesso. 3. **SQL Completo dello Schema**: Fornisci le istruzioni CREATE TABLE complete con: - Chiavi primarie (specifica UUID vs auto-increment e perché) - Chiavi esterne con azioni ON DELETE / ON UPDATE appropriate - Vincoli NOT NULL dove appropriato - Vincoli CHECK per colonne di tipo enum - Valori DEFAULT dove sensati - Timestamp (created_at, updated_at) con default appropriati 4. **Strategia degli Indici**: Per ogni indice: - L'istruzione CREATE INDEX - Quale pattern di query supporta - Se è un indice B-tree, hash, GIN o GiST (specifico per il motore) - Impatto atteso sulle performance in scrittura 5. **Note sulla Migrazione**: Eventuali considerazioni per il deploy di questo schema, incluso l'ordine di creazione delle tabelle (per soddisfare le dipendenze delle chiavi esterne) e suggerimenti per i dati seed.
Usage Tips
- Descrivi le entità in termini di business, non di tabelle: Scrivi "Un utente può appartenere a più progetti" invece di "Serve una tabella di giunzione user_projects." Lascia che l'AI gestisca la traduzione, così può identificare la struttura ottimale, che potrebbe differire dalla tua assunzione iniziale.
- Includi la scala prevista fin dall'inizio: Uno schema per 1.000 righe e uno per 10 milioni di righe possono essere molto diversi. Le informazioni sulla scala guidano le decisioni su indicizzazione, partizionamento e denormalizzazione.
- Specifica il motore di database: PostgreSQL supporta indici parziali, colonne JSONB e tipi array. MySQL gestisce gli enum in modo diverso. SQL Server ha un comportamento unico per gli indici clustered. I consigli specifici per il motore sono significativamente più utili.
- Rivedi con attenzione le note sulla normalizzazione: Se l'AI ha denormalizzato qualcosa (es. memorizzare un conteggio calcolato sulla tabella padre), assicurati di condividere il compromesso prima di implementare. Puoi fare domande di approfondimento su decisioni specifiche.
- Estendi con prompt di follow-up: Dopo aver ottenuto lo schema base, chiedi all'AI di aggiungere audit logging, row-level security, supporto soft delete o script di migrazione per il tuo ORM (Prisma, Drizzle, TypeORM, Alembic).
Get more from this prompt
Save it, score it with AI, optimize it, and track every version. Free to start.