Codice First vs. Database First

Quando progetto e creo il software su cui lavoro, in genere progetto e creo prima le tabelle SQL back-end, quindi passiamo alla programmazione effettiva. Il progetto a cui sto attualmente lavorando mi ha lasciato perplesso. Ciò è probabilmente dovuto alla mancanza di requisiti validi e solidi, ma sfortunatamente c'è poco che posso fare al riguardo questa volta. È un tipo di situazione "basta che accada", ma sto divagando.

Sto pensando di capovolgere il mio flusso di lavoro e di creare prima l'interfaccia utente e le classi del modello di dati nella speranza che risolverlo mi chiarisca come sarà il mio schema di database. E 'questa una buona idea? Sono nervoso che finirò con un'interfaccia utente e ancora non ho idea di come strutturare il db.

Se qualcuno è curioso, sto usando SQL Server come back-end e MS Access come applicazione front-end. (L'accesso non è nemmeno una mia scelta ... quindi per favore non odiarlo troppo male.)

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

Ad esempio, è possibile creare il proprio modello di dati in modo incrementale implementando un singolo caso d'uso alla volta con la sola persistenza in memoria (o qualsiasi altra cosa facile da implementare). Quando ritieni di aver implementato abbastanza casi d'uso per delineare le entità di base, puoi sostituire la persistenza in memoria con un database reale e quindi continuare a perfezionare lo schema mentre procedi, un caso d'uso alla volta.

Ciò toglie l'attenzione dal database e lo sposta al centro del problema: le regole aziendali. Se inizi implementando le regole di business, alla fine troverai (attraverso un processo molto simile alla selezione naturale), quali dati sono veramente necessari all'azienda. Se inizi modellando il database, senza il feedback se tali dati sono veramente necessari (o in quel formato, o in quel livello di normalizzazione, ecc ...), finirai per fare un sacco di ritardi in lo schema (che potrebbe richiedere pesanti procedure di migrazione, se l'azienda è già in esecuzione con esso), oppure dovrai implementare "soluzioni alternative" nelle regole aziendali per compensare il modello di dati stonato.

TL; DR: il database dipende dall'azienda - è definito da loro. Non avrai bisogno dei dati a meno che tu non abbia un processo che funziona con esso (un rapporto è anche un processo). Implementa prima il processo e troverai i dati di cui ha bisogno. Modella prima i dati e potresti essere in grado di contare quanti presupposti erano errati quando li hai modellati 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 guidato dai test e un focus sul disaccoppiamento della tua architettura dai dettagli che mettiti in mezzo (suggerimento: database). Circa l'ultimo, questo discorso riassume abbastanza bene l'idea.

Un'analisi della causa alla radice suggerisce che questo problema non riguarda il metodo, ma la mancanza di una specifica. Senza uno, non importa cosa scrivi per primo, lo butterai via comunque.

Fatevi un favore e fate alcune analisi di base dei sistemi: identificate alcuni utenti a vari livelli, compilate un questionario rapido e sporco, quindi spegnete la macchina, prendete un po 'di caffè e biscotti / ciambelle (o qualsiasi cosa ingrassi le ruote), quindi fate una passeggiata per loro scrivanie, chiedete loro cosa fanno e cosa devono sapere / registrare per fare il loro lavoro anche se sembra ovvio - chiedete ancora. Non preoccuparti di quanto siano importanti, se sono troppo occupati, prendi un accordo per tornare un'altra volta o lasciarlo con loro.

Una volta ottenuto, dovresti essere in grado di iniziare a costruire qualsiasi cosa tu pensi che ti darà i migliori risultati e attendere che arrivi il resto delle specifiche.

La mia esperienza è la seguente:

• Nella maggior parte dei progetti su cui ho lavorato, abbiamo progettato prima il database.
• Spesso i dati esistono già in fogli di calcolo, database legacy, documenti cartacei, ecc. Questi dati ti daranno suggerimenti sulle tabelle di cui hai bisogno per conservarli.
• Spesso un processo è già in uso, ma manualmente o utilizzando diversi strumenti diversi che non sono automatizzati, non interagiscono e / o non sono conformi agli standard.
• Una volta che hai un modello di database semi-maturo puoi iniziare a progettare moduli prototipo, finestre ecc., Che leggono e scrivono in quel database.
• Mentre continui, saranno necessarie alcune modifiche per adattarsi a cose non contemplate all'inizio.

Ricorda anche:

• Non è più un mondo con un'unica app <-> 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 utilizzando lo stesso database.

Conclusione: ti consiglio di progettare prima il database.

Stavo per dire Database in primo luogo poiché ho molta esperienza con grandi progetti 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".

Un buon insieme ben specificato di requisiti aziendali porta a un buon insieme di requisiti funzionali. Se si dispone di una buona serie di requisiti funzionali, il modello di dati e le specifiche del modulo si inseriscono senza troppi sforzi.

Dal momento che questo sembra così fluido / non specificato, farei prima la GUI del frontend - sembra proprio ciò di cui hai bisogno per ottenere risposte, supporto, tempo e feedback dagli stakeholder, giusto? A loro non importa delle tue brillanti tabelle normalizzate, vincoli di chiavi esterne ed eliminazioni a cascata. Ma una fantastica GUI con molti colori brillanti - beh, questo è il massimo!

Per il "database" di backend iniziale, utilizzare qualcosa di estremamente semplice, forse solo chiavi / valori memorizzati in un file. Non ho familiarità con MS Access, quindi non so quale sarebbe il backend "più leggero". (una tabella di fogli di calcolo?) Qualunque cosa sia veloce e sporca, hai intenzione di buttarla via.

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

Ora, forse i tuoi stakeholder sono esperti di DB - questo è stato il caso con me a volte! - in tal caso, eseguire alcuni progetti DB.

Poiché i requisiti non sono chiari, si può iniziare con un modello di dati molto rudimentale con gli elementi chiave di cui si saprà di aver bisogno, forse solo tabelle di base e PK per iniziare. Il resto dei dati, serializzare su binario o XML e archiviare il BLOB nel database per iniziare. Ciò dovrebbe consentire di sviluppare l'interfaccia utente e il livello aziendale (livello intermedio) senza un modello completamente relazionale, ma si avrà comunque la persistenza di salvare e recuperare e ricerche chiave semplici, se necessario.

Ad esempio, forse hai una persona, quindi hai un PK di ID persona. Il resto degli attributi non è noto, quindi inizia con una tabella Persona con un ID persona PK e un'altra colonna che memorizzerà il BLOB, tutti i dati della 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 si tratta solo di cambiare la persistenza da BLOB a relazionale nel livello di accesso ai dati. Ma tutto il resto, l'interfaccia utente delle regole di business, ecc continuerà a funzionare. Si noti che ciò aggiunge un po 'di tempo al progetto, ma consente la completa flessibilità di aggiungere e rilasciare le cose secondo necessità senza cambiare il modello relazionale fino a quando le cose non diventano più solide

La ricerca potrebbe essere ritardata poiché non è possibile eseguire una query su un BLOB in modo che il modello si stabilizzi, iniziare a memorizzare i dati che devono essere cercati nelle colonne relazionali.

Fondamentalmente si inizia con un modello tabulare e si passa a un modello relazionale man mano che il progetto avanza.

Oppure, consolidare 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 sta per manipolare 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 inviarli al tuo datore di lavoro, quindi hanno qualcosa a cui sparare. Oppure crea prima una GUI, dipende dal tipo di datore di lavoro che funziona meglio :)