it-swarm.it

È 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. Progetta il database nel miglior modo 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 cosa/dove/come dei dati cambia durante tutto il ciclo di sviluppo dell'applicazione.
  2. Progetta il database man mano che l'applicazione prende forma . 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 il codice dell'applicazione e lo sviluppo del database.

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

57
Thomas Stringer

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, 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 suddivisione di tabelle, modifica delle relazioni, ecc. Accadranno, ma nelle "isole" localizzate e il modello + la progettazione di base rimarranno invariati.

42
gbn

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 no ) verificarsi in futuro, quindi progetta per ciò che sai è necessario, non per ciò che potrebbe essere.

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

27

Il modello di dati logici dovrebbe acquisire in modo efficace i requisiti aziendali dell'applicazione. La progettazione del database fisico dovrebbe basarsi sul modello di dati logici combinato con le modifiche necessarie che l'utente ritiene che un DBA sia necessario per massimizzare l'efficienza del proprio 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 tuoi modellatori di dati (o analisti di sistema) non hanno sufficientemente tradotto i requisiti dagli 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.

12
RobPaller

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 di essere più intelligenti o più consapevoli o di 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 gli utenti sui loro processi di pensiero e le loro 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 è IS scoperta di 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. Imparo che una colonna deve spostarsi in una nuova tabella padre perché ci sono più tipi. Imparo che la lista di lavoro deve avere ordini permanenti che don non viene dal sistema di ordini integrato. Imparo ogni sorta di cose!

Secondo me, questa è una vittoria enorme.

11
ErikE

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. Essere 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 dovrebbe essere eseguita in ogni iterazione senza errori.

10
nvogel

Nel mondo dell'architettura, la frase "La forma segue la funzione" è stata coniata e successivamente rispettata 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 in RAM (trattandolo così come un canale di dati) e avranno un database, come MySQL o PostgreSQL, che si comporta semplicemente come un'unità di memorizzazione dei dati.

L'incentivo per l'utilizzo di un database dovrebbe essere quello di guardarlo correttamente: come un RDBMS. Sì, a Relazionale Sistema di gestione del database. 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 continui. Tuttavia, ciò dovrebbe ridurre al minimo le modifiche al database a lungo termine.

9
RolandoMySQLDBA

Penso che dovrebbe essere fatto prima che ci sia un reale 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 frequentemente 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. L'archiviazione principale dei dati è 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)

9
Joe

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 a cascata. Se i dati sono lì, posso recuperarli se gli strumenti che uso 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?

8
Fabricio Araujo

Come al solito, dipende;)

Ad esempio, supponiamo di avere un prototipo funzionante di piccole dimensioni sviluppato in Python e utilizzando file flat, e gli utenti sono 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 questi 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 live OLTP senza tempi di inattività e con basso rischio, siamo a nostro agio con la possibilità di refactoring del database.

7
A-K