Code First vs. Database First

Che cosa è venuto prima, il processo o i dati utilizzati da quel processo? So che questa è una specie di "pollo o uovo", ma nel caso del software, credo che sia il processo.

Ad esempio, puoi costruire il tuo modello di dati in modo incrementale implementando un singolo caso d'uso alla volta con la sola persistenza in memoria (o qualsiasi cosa facile da implementare). Quando ritieni di aver implementato un numero sufficiente di casi d'uso per delineare le entità di base, puoi sostituire la persistenza in memoria con un vero database, e poi continuare a perfezionare lo schema mentre procedi, un caso d'uso alla volta.

Questo distoglie l'attenzione dal database e lo sposta al centro del problema: le regole aziendali. Se inizi a implementare le regole aziendali, alla fine troverai (tramite un processo molto simile a Natural Selection, tra l'altro) quali dati sono veramente necessari per l'azienda. Se inizi a modellare il database, senza il feedback sul fatto che quei dati siano realmente necessari (o in quel formato, o in quel livello di normalizzazione, ecc ...), finirai per fare un sacco di ritocchi in ritardo lo schema (che potrebbe richiedere pesanti procedure di migrazione, se l'azienda è già in esecuzione con esso), o dovrai implementare "soluzioni" nelle regole di business per compensare il modello di dati out-of-tune.

TL; DR: il database dipende dal business - è definito da loro. Non avrai bisogno dei dati se non hai un processo che funziona con esso (un report è anche un processo). Implementa prima il processo e troverai i dati di cui ha bisogno. Modella i dati per primi e potresti essere in grado di contare quante ipotesi erano sbagliate quando hai modellato per la prima volta.

Un po 'fuori tema ma molto importante: il flusso di lavoro che descrivo viene spesso utilizzato insieme a pratiche molto importanti come "La cosa più semplice che potrebbe funzionare", lo sviluppo basato sui test e un focus sul disaccoppiamento della tua architettura da i dettagli che ti intralciano (suggerimento: database). Riguardo l'ultimo, questo talk riassume abbastanza bene l'idea.

Un'analisi della causa principale suggerisce che questo problema non è uno dei metodi, ma è la mancanza di una specifica. Senza uno non importa quello che scrivi per primo - lo butti via comunque

Fai un favore a te stesso e fai qualche analisi di base dei sistemi - identifica alcuni utenti a vari livelli, crea un rapido e amp; questionario sporco poi spegni la macchina, prendi un caffè e biscotti / ciambelle (o qualsiasi altro grasso), poi fai una passeggiata alla scrivania, chiedi loro cosa fanno e cosa hanno bisogno di sapere / registrare per fare il loro lavoro anche se sembra ovvio - chiedi ancora. Non preoccuparti di quanto siano importanti, se sono troppo occupati, quindi fai un accordo per tornare un'altra volta o lasciarlo con loro.

Una volta che avresti dovuto essere in grado di iniziare a costruire tutto ciò che pensi ti darà i migliori risultati e aspettare che arrivi il resto delle specifiche.

Stavo per dire Database First poiché ho molta esperienza con progetti di grandi dimensioni e hai davvero bisogno di un solido modello di dati se hai molti sviluppatori che lavorano in parallelo.

Ma poi ci ho pensato un po 'di più e mi sono reso conto che quello che stavamo davvero facendo sui grandi progetti di maggior successo erano i "requisiti prima di tutto".

Un insieme ben definito di requisiti aziendali, conduce a un buon insieme di requisiti funzionali. Se si dispone di un buon insieme di requisiti funzionali, il modello di dati e le specifiche del modulo rientrano in una posizione senza grandi sforzi.

La mia esperienza è la seguente:

• Nella maggior parte dei progetti su cui ho lavorato, abbiamo progettato il database per primo.
• Spesso i dati esistono già in fogli di lavoro, database legacy, carta, ecc. Questi dati ti daranno suggerimenti sulle tabelle che ti servono per tenerlo.
• Spesso un processo è già in uso, ma manualmente o utilizzando diversi strumenti disparati che non sono automatizzati, non interagiscono e / o non sono conformi agli standard.
• Una volta ottenuto un modello di database semi-maturo, è possibile iniziare a progettare moduli prototipo, finestre ecc. che leggono e scrivono su quel database.
• Man mano che prosegui, alcune modifiche saranno necessarie per accogliere le cose non contemplate all'inizio.

Ricorda anche:

• Non è più un mondo con una sola applicazione < - > un database. Forse la tua app dovrà leggere o scrivere dati da più di un database o la tua soluzione comprenderà più di un'app che utilizza lo stesso database.

Conclusione: ti consiglio di progettare il database prima.

Dato che sembra così fluido / non specificato, farei prima la GUI del frontend, che suona come se fosse necessario ottenere risposte, supporto, tempo e feedback dagli stakeholder, giusto? Non si preoccupano delle tue brillanti tabelle normalizzate e dei vincoli delle chiavi esterne e delle eliminazioni a cascata. Ma una GUI fantastica con un sacco di colori brillanti - beh, questo è di prim'ordine!

Per il "database" iniziale di back-end, usa qualcosa di estremamente semplice, magari solo chiavi / valori memorizzati in un file. Non ho familiarità con MS Access, quindi non so quale sarebbe il backend "più leggero". (un tavolo spreadsheed?) Qualunque cosa sia veloce e sporca, pensa di buttarla via.

Se puoi, utilizza un aspetto divertente nella GUI per chiarire che si tratta di un prototipo. Se tutto il resto fallisce, usa gli indici.

Ora, forse i tuoi stakeholder sono esperti di DB - a volte è successo a me! - nel qual caso, fai alcuni progetti di DB.

Poiché i requisiti non sono chiari, è possibile iniziare con un modello di dati molto rudimentale con gli elementi chiave di cui si avrà la certezza, magari solo le tabelle di base e i PK da avviare. Il resto dei dati, serializza su binario o XML e memorizza il BLOB nel database per iniziare. Ciò dovrebbe consentire a uno di sviluppare l'interfaccia utente e il livello aziendale (livello intermedio) senza un modello completamente relazionale, ma si avrà comunque la persistenza per salvare e recuperare e semplici ricerche di chiavi secondo necessità.

Ad esempio, potresti avere una persona, quindi hai un PK di Id Person. Il resto degli attributi non è noto, quindi inizia solo con una tabella Persona con un ID persona PK e un'altra colonna che memorizzerà il Blob, tutti i dati relativi alla persona.

Una volta che i requisiti si solidificano, prendi i tuoi Blob ed estrai tutte le tabelle e le colonne necessarie e rendi il modello relazionale. Quindi è solo questione di cambiare la persistenza da un BLOB a relazionale nel livello di accesso ai dati. Ma tutto il resto, le regole aziendali dell'interfaccia utente ecc. Funzioneranno ancora. Nota, questo aggiunge un po 'di tempo al progetto, ma dà la possibilità di completare la flessibilità per aggiungere e rilasciare le cose secondo necessità senza modificare il modello relazionale fino a quando le cose non diventano più solide

La ricerca potrebbe essere ritardata in quanto non è possibile interrogare un BLOB in modo che il modello si stabilizzi, avviare la memorizzazione dei dati che devono essere ricercati nelle colonne relazionali.

Fondamentalmente si inizia con un modello tabulare e si passa a uno relazionale mentre il progetto avanza.

Oppure, consolida i requisiti prima di iniziare qualsiasi lavoro in modo da poter sviluppare inizialmente un modello relazionale.

In generale, penso che il codice venga dopo i dati perché il codice manipolerà i dati.

Se i requisiti non sono chiari, è possibile creare un modello di dati della propria interpretazione dei requisiti. La cosa migliore è forse scrivere alcuni requisiti e inviarlo al tuo datore di lavoro, quindi hanno qualcosa da sparare. Oppure creare prima una GUI, dipende dal tipo di datore di lavoro che funziona meglio:)