Quando scrivi un post sul blog sulla modellazione del database, devi essere preparato che il tuo modello astratto non soddisfi le esigenze della maggior parte dei lettori. Il motivo è semplice. I modelli di database reali vengono solitamente creati in stretta relazione a specifici requisiti aziendali e di sviluppo, mentre i modelli di blog non lo sono.
Nelle ultime settimane ho scritto post sul blog sulla creazione di modelli di database. Gli argomenti andavano da un approccio generale alla modellazione di database attraverso un semplice forum online a un modello per un sondaggio online più complesso.
Per ogni modello di database che creo, cerco di comprendere chiaramente il dominio aziendale e di elaborare mentalmente il quadro generale del modello.
La sfida dello sviluppo di database astratti
Normalmente, come soluzione architetto , prendo requisiti aziendali specifici e li converto nei dettagli tecnici di ciò che deve essere creato dal lato tecnico:tradurre dal linguaggio commerciale al linguaggio tecnico, progettando gli algoritmi ad alto livello e modellando i requisiti di dati per gli algoritmi.
Sfortunatamente, non posso bloggare sui modelli di database del mondo reale che creo al lavoro. Da un lato, sono molto specifici per il dominio aziendale e dall'altro sono limitato da accordi di riservatezza. Per il blog creo un puramente abstract concetto senza requisiti aziendali specifici tranne quelli che immagino esistano all'interno del dominio aziendale. Ora, va bene; Ho una buona immaginazione e sottolineo frequentemente che le vostre esigenze possono essere diverse quando descrivo le scelte che sto facendo. Ma questo processo di blogging mi ha fatto pensare a quanto sia diverso questo processo dalla creazione dei modelli in un progetto reale.
Il processo di sviluppo della vita reale
In una situazione reale, lavorerei a stretto contatto con il team di sviluppo dopo aver creato la soluzione di alto livello e la progettazione tecnica in un ambiente interattivo modo che il modello soddisfi le esigenze di sviluppo.
Gli sviluppatori potrebbero lamentarsi del fatto che il modello di dati è troppo normalizzato per supportare prestazioni elevate o potrebbero richiedere un'ulteriore normalizzazione in determinate aree. Se mancassero chiavi alternative, gli sviluppatori si lamenterebbero abbastanza rapidamente e lo noteremo anche durante i test delle prestazioni del database.
Consideriamo quali dovrebbero essere le lunghezze esatte dei campi in base alla lunghezza massima dei dati da memorizzare e alla progettazione delle schermate per l'immissione e la visualizzazione dei dati. Naturalmente, le lunghezze esatte dei campi in un modello di database concettuale non sono importanti.
Lavoreremo attraverso esempi di quali dati verranno archiviati nelle tabelle e come verranno utilizzati dall'applicazione e creeremo script per precompilare le tabelle per il test unitario dell'applicazione. In questo modo, prenderemmo i casi d'angolo per garantire che il modello supporti i limiti dell'applicazione.
Quindi, fondamentalmente, massaggieremmo il modello fino a quando non supporta davvero i requisiti aziendali e non funzionali del sistema utilizzando un processo iterativo fino a quando non avremo evoluto un modello in qualcosa che tutti possiamo accettare nonostante i compromessi in esso incorporati.
Come ho detto, sarebbe un processo molto iterativo che potrebbe continuare per molti mesi durante lo sviluppo del codice dell'applicazione, delle interfacce utente e delle interfacce dell'applicazione.
Limitazioni del feedback ben intenzionato
Nell'attuale situazione dei blog, mentre il mio numero limitato di lettori mi fornisce feedback su problemi e sfide che osservano con i modelli, è necessariamente superficiale. Dubito che qualcuno dei lettori stia utilizzando direttamente i modelli per creare un'applicazione e scoprire cosa funziona davvero e dove ci sono problemi.
Quindi i commenti come "modello non ben congegnato" sono quasi sicuramente giusti. D'altra parte, "mancano FK" sono abbastanza precisi, ma spero di aver spiegato nel testo dell'articolo perché sto includendo una chiave esterna o meno.
Conclusione
Ora, per favore, non leggere questo post come un reclamo o un commento sul feedback che i lettori stanno facendo, piuttosto sto riflettendo sulla difficoltà di creare un modello di database quando non ci si trova in un ambiente che consente uno scambio interattivo con un processo di sviluppo.
Probabilmente ci sono altre situazioni in cui i modellatori di database sono tagliati fuori dal processo di sviluppo, ma ora ho capito quanto sarebbe pericoloso e quanto sarebbero soggetti a problemi.
Riuscite a immaginare un modello di database che non è mai cambiato? Mai una singola regolazione di una colonna, mai l'aggiunta di una chiave esterna, mai la necessità di una nuova tabella. Onestamente, l'unica situazione che posso immaginare è quando l'applicazione che utilizza il database non è più in evoluzione e ha raggiunto un vicolo cieco:fine vita.
