È necessario progettare il database prima che venga scritto il codice dell'applicazione?

Qual è il modo più semplice ed efficiente per progettare un database? Dal mio punto di vista, ci sono un paio di opzioni per la progettazione dell'archivio dati di un'applicazione:

1. Progettare il database nel modo migliore possibile inizialmente prima di scrivere qualsiasi codice dell'applicazione . Questo ti dà il vantaggio di avere una struttura di dati di base su cui lavorare. Lo svantaggio di questo, secondo me, è che avrai molte modifiche come specifiche dell'applicazione che influenzano il cosa / dove / come i dati cambiano durante il ciclo di sviluppo dell'applicazione.
2. Progettare il database man mano che l'applicazione viene realizzata . Quando sono necessari alcuni oggetti di database durante la scrittura dell'applicazione, si sviluppa il database parallelamente (in ordine cronologico) all'applicazione. I vantaggi sarebbero meno modifiche alla struttura del database come la vedo io. Lo svantaggio sarebbe la divisione del tempo e lo sforzo di sviluppo tra codice dell'applicazione e sviluppo del database.

Nella tua esperienza, quale ritieni sia il metodo più produttivo ed efficiente?

Oltre ad altre risposte ...

Catturare prima il modello concettuale dovrebbe definire ambito e requisiti. Da questo, puoi derivare i tuoi modelli di dati logici e fisici.

Una volta che questo è per lo più statico, allora hai un database stabile su cui costruire la tua applicazione. Questo è contrario alla tua prima opzione.

Il tuo secondo punto finirà in una palla di fango disordinata e non mantenibile . Il modello di dati non sarà mai risolto: se non lo hai progettato in anticipo, non avrai tempo di ripararlo prima della spedizione. Sarai troppo impegnato ad hackerare cose insieme.

Piccole modifiche allo schema, combinazione o divisione di tabelle, modifica delle relazioni, ecc. Accadranno, ma nelle "isole" localizzate e il modello + la progettazione di base rimarranno invariati.

Ti verrà difficile trovare un reparto software moderno che non utilizza una variante di Agile. I DBA in confronto sono bloccati nei secoli bui, con il tipo di pensiero che la risposta di @ RobPaller contenga ancora un posto comune.

Modificare uno schema di database non è mai stato così facile come modificare il codice, motivo per cui c'è stata riluttanza ad adottare un approccio agile allo sviluppo e alla manutenzione del database. Ora che abbiamo gli strumenti e le tecniche per operare in modo simile agli sviluppatori, dovremmo assolutamente farlo. Solo perché non è facile cambiare schema, non significa che non puoi e che non dovresti.

Non sto sostenendo un approccio casuale alla progettazione di database (vedi commenti), ma solo un approccio che rispecchi più da vicino quello di un team di sviluppo agile. Se fai parte di un progetto agile, non avrai requisiti di lavoro che potrebbero ( o meno ) verificarsi in futuro, quindi progetta ciò che sai è necessario, non quello che potrebbe essere.

Immagino che questo dia il mio voto con la tua opzione 2 e sospetto che potrei trovarmi al freddo su questo!

Il modello di dati logici dovrebbe acquisire in modo efficace i requisiti aziendali dell'applicazione. La progettazione del tuo database fisico dovrebbe essere basata sul modello logico di dati combinato con le modifiche necessarie che ritieni necessarie come DBA per massimizzare l'efficienza del tuo RDBMS.

Se si rileva che è necessario apportare numerose modifiche alla progettazione del database sottostante durante il ciclo di vita dello sviluppo software dell'applicazione, è indicativo di due cose:

1. Scope creep - Stai permettendo l'introduzione di nuovi requisiti in un momento inappropriato.
2. Requisiti aziendali insufficienti : i vostri modellatori di dati (o analisti di sistema) non hanno sufficientemente tradotto i requisiti degli analisti aziendali. Ciò ha comportato un modello di dati incompleto o errato per supportare i requisiti dell'applicazione.

Ciò detto, una volta che un'applicazione è stata trasferita alla produzione, non è raro tornare indietro e apportare modifiche iterative al modello di dati per supportare la naturale evoluzione dell'applicazione o dei processi aziendali sottostanti.

Spero che sia di aiuto.

Ho avuto il lusso di progettare diversi database di media complessità, tutti utilizzati nelle aziende, con vari front-end tra cui web, Access e C #.

Di solito, mi sono seduto e ho elaborato in anticipo lo schema del database. Questo ha sempre avuto più senso per me. Tuttavia, non c'è stato un singolo caso in cui non ho finito per apportare modifiche, aggiungere nuovi tavoli o vivere con aspetti che mi davano fastidio ed erano praticamente troppo tardi per risolvere.

Non credo che la cura sia scrivere prima il codice. E non penso che il problema sia "requisiti aziendali insufficienti" o almeno non uno che avrebbe potuto essere risolto completamente. Gli utenti non sanno di cosa hanno bisogno e non ho il potere di farli pensare in modo più duro o essere più intelligenti o più consapevoli o rispondere meglio alle mie domande. Oppure discutono e mi viene ordinato di fare qualcosa in un certo modo.

I sistemi che costruisco sono di solito in nuove aree in cui nessuno è mai entrato prima. Non ho il buy-in da parte dell'organizzazione, delle risorse o degli strumenti per fare il tipo di lavoro che un team di sviluppo di professionisti del design di alto livello potrebbe ricevere in una squadra dieci volte quello che faccio per costruire le cose due volte.

Sono bravo in quello che faccio. Ma c'è solo uno di me che lo fa in un ambiente che "non fa sviluppo".

Detto questo, sto migliorando nello scoprire le regole aziendali. E vedo una specie di terza opzione:

Prima di progettare il database e prima di scrivere qualsiasi codice, disegnare schermate grezze che mostrano come funzionerà l'applicazione. Devono essere disegnati a mano per impedire a chiunque di commentare font o dimensioni o dimensioni - si desidera solo la funzione.

Con i lucidi e i pezzi di carta è possibile passare da una parte all'altra, fare in modo che una persona sia il computer, due siano utenti non tecnici esperti in materia (due in modo che parlino ad alta voce) e una persona lì come facilitatore che prende appunti e disegna fuori gli utenti sui loro processi di pensiero e confusioni. Gli utenti "fanno clic" e trascinano e scrivono nelle caselle, il "computer" aggiorna lo schermo e tutti possono sperimentare il design. Imparerai cose che altrimenti non avresti potuto imparare fino a lontano nel processo di sviluppo.

Forse mi sto contraddicendo, forse è una scoperta dei requisiti migliori. Ma l'idea è di progettare prima l'applicazione, senza scrivere alcun codice. Ho iniziato a farlo su piccola scala e funziona! Nonostante i problemi nel mio ambiente, mi sta aiutando a progettare meglio il database dall'inizio. Ho appreso che una colonna deve spostarsi in una nuova tabella padre perché ci sono più tipi. Apprendo che la lista di lavoro deve avere ordini permanenti che non provengono dal sistema di ordini integrato. Imparo ogni sorta di cose!

Secondo me, questa è una vittoria enorme.

Per la maggior parte degli scopi sceglierei l'opzione 2: Costruisci il database in parallelo con gli altri componenti. Ove possibile, adottare un approccio iterativo e fornire funzionalità end-to-end durante la costruzione di ogni pezzo.

Questo richiede un certo grado di disciplina del progetto. Applicare rigorosamente la normalizzazione (Boyce-Codd / Fifth Normal Form) ogni volta che si modifica il database in modo da mantenere la qualità e non finire con un modello ad hoc e incoerente. Sii il più aggressivo possibile con le regole aziendali e i vincoli del database degli operatori. In caso di dubbio è meglio imporre un vincolo in anticipo - puoi sempre eliminarlo in seguito. Sii intelligente sull'ordine in cui implementi i componenti architettonici in modo da ridurre al minimo il debito tecnico. Avere una buona serie di linee guida per la progettazione di database in cui tutto il team di sviluppo acquista.

Tutto ciò ovviamente deve andare di pari passo con altre buone pratiche di ingegneria dello sviluppo: integrazione continua, automazione dei test e soprattutto dal punto di vista del database, creazione di dati di test. La creazione di dati di test di dati di dimensioni realistiche deve essere eseguita in ogni iterazione senza errori.

Nel mondo dell'architettura, la frase "La forma segue la funzione" è stata coniata e successivamente seguita durante la costruzione di edifici alti. Lo stesso dovrebbe essere applicato all'infrastruttura DB e allo sviluppo delle applicazioni.

Immagina di scrivere un'app, decidendo al volo che hai bisogno di un tavolo qui e un tavolo lì. Al termine della tua app, hai un numero enorme di tabelle trattate come array. Guardando tutti i tavoli fianco a fianco, i tavoli sembreranno sicuramente non avere rima o motivo.

Sfortunatamente, alcuni negozi di sviluppatori prenderanno qualcosa come memcached, lo caricheranno con i dati nella RAM (trattandoli così come un condotto di dati) e avranno un database, come MySQL o PostgreSQL, che si comporta semplicemente come un'unità di archiviazione dei dati.

L'incentivo per l'utilizzo di un database dovrebbe essere quello di guardarlo correttamente: come un RDBMS. Sì, un sistema di gestione di database relazionali . Quando si utilizza un RDBMS, l'obiettivo iniziale non dovrebbe essere solo quello di stabilire tabelle per l'archiviazione, ma anche per il recupero. Le relazioni tra le tabelle devono essere modellate in base ai dati che si desidera visualizzare e al modo in cui vengono presentati. Ciò dovrebbe basarsi sulla coesione e l'integrità dei dati insieme a regole commerciali note. Tali regole aziendali possono essere codificate nella tua app (Perl, Python, Ruby, Java, ecc.) O nel database .

CONCLUSIONE

Andrei sicuramente con l'opzione 1. Ci vogliono una pianificazione, una modellizzazione dei dati e un'analisi dei dati in corso. Tuttavia, ciò dovrebbe minimizzare le modifiche del database a lungo termine.

Penso che dovrebbe essere fatto prima che ci sia un vero codice per l'applicazione, ma non prima che l'applicazione sia progettata.

Il mio flusso di lavoro tipico, se lavoro da solo è:

1. Determina cosa deve fare l'applicazione
2. Verifica se è possibile suddividere una delle attività per componenti riutilizzabili
3. Determina come ogni attività deve interagire con l'archiviazione dei dati: che tipo di domande verranno poste ai dati, con quale frequenza scriveranno, ecc.
4. Progettare il database in modo che sia in grado di rispondere a tutte le domande che dobbiamo porgli e che funzioni bene per le attività più frequenti.
5. Scrivi l'applicazione.

Dato che lavoro spesso come parte di una squadra e siamo geograficamente dispersi (e attraverso i fusi orari), tendiamo ad avere una riunione iniziale di kickoff:

1. Determina cosa deve fare l'applicazione.
2. Determinare dove sono i punti positivi per suddividere l'applicazione in componenti autonomi
3. Determina come ciascun componente dovrà interagire con gli altri.
4. Concordare un'API per ciascuna delle interazioni.

Quindi, torniamo a casa, scriviamo la nostra parte e se un componente ha bisogno della propria memoria locale, purché il manutentore di quella parte mantenga coerente l'API con il proprio modulo. La memoria principale dei dati viene gestita come un modulo con la propria API e ci si aspetta che le persone vi scrivano. (nei casi in cui la velocità del DB è critica, l'API è la definizione della tabella e, se vengono apportate modifiche, utilizziamo le viste o qualche altro meccanismo per presentare la versione precedente fino a quando tutti i moduli possono essere aggiornati)

Ho in mente la seguente regola: "puoi ottenere dal database solo le informazioni che hai i dati da generare". Quindi, disegno prima il database e successivamente il codice.

Perché? Indipendentemente dalla metodologia / lingua / set di strumenti che utilizzo, se tutti i dati rilevanti sono ben progettati e memorizzati nel DB, posso recuperarli. Non importa se si trova in C # / Delphi / FORTRAN / COBOL / Assembly / VBA o Crystal Reports; OO progettato o evento / dati / qualunque sia guidato; agile o cascata. Se i dati sono lì, posso recuperarli se gli strumenti che utilizzo possono connettersi al database. Posso creare i rapporti sulle vendite se posso SELEZIONARE gli ordini per i ricavi del trimestre, anche se devo scriverlo byte per byte su Assembly.

Se i dati rilevanti non sono presenti o anche se sono presenti ma (non) strutturati in un modo che non riesco a recuperare le informazioni di cui ho bisogno - come codificarli?

Come al solito, dipende;)

Ad esempio, supponiamo di avere un prototipo funzionante di piccole dimensioni sviluppato in Python e che utilizza file flat e che gli utenti siano soddisfatti delle funzionalità del prototipo, quindi tutto ciò che dobbiamo fare è produrlo, usando RDBMS come back-end . In questo caso, è ragionevole aspettarsi di farlo bene la prima volta: il problema è piccolo e ben definito. In tali casi è possibile progettare in anticipo.

D'altra parte, quando stiamo scoprendo i requisiti in un ambiente Agile, abbiamo bisogno di alcune iterazioni per capirli meglio. In tali situazioni il database si evolve con il resto dell'applicazione. Questo è ciò che facciamo di solito. Poiché siamo in grado di eseguire il refactoring delle tabelle OLTP live senza tempi di inattività e con un rischio ridotto, siamo a nostro agio con la possibilità di refactoring del database.