Quando i programmatori usano il primo approccio al codice?

Uso sempre il codice per primo e non penserei mai ai dati prima, a meno che non debba integrarmi con un database esistente. Perché?

1. Invece di iniziare a capire come si presenta il database, comincio a capire cosa fa la mia applicazione.
2. Non devo riconciliare il mio design di database iniziale con funzionalità, pagine web, API ecc. Invece, faccio tutte le attività di progettazione insieme.
3. Il costo del "pre-design" può essere elevato, soprattutto se qualcosa è cambiato negli obiettivi generali dell'applicazione che causa un cambiamento significativo del modello del database.

Se una squadra ha:

• Un DBA,

• O uno sviluppatore che è anche un po 'informato sui database,

allora la squadra sarà incline a evitare l'approccio code-first. È lo stesso che utilizzare gli editor WYSIWYG quando il tuo team conosce l'HTML: mentre il lavoro può essere eseguito con un WYSIWYG, devi comunque farlo manualmente se hai bisogno di un codice scritto e gestibile decentemente.

Questo non ha nulla a che fare con le stored procedure in particolare (e trovo la tua affermazione circa le prestazioni sopravvalutate), ma piuttosto con la qualità del design stesso. Ovviamente, anche il numero di funzioni che è possibile utilizzare (stored procedure, colonne calcolate, FILESTREAM, ecc.) È importante.

Un altro aspetto da considerare è che lo schema del database è solo uno degli aspetti da considerare per un prodotto completo. Un altro aspetto potrebbe essere la strategia di backup, la federazione (bilanciamento del carico) e la manutenzione generale a lungo termine del server.

D'altra parte, l'approccio code-first è fantastico:

• per i team senza DBA e senza persone che sanno come sono progettati i database. Possono provare a farlo a mano (e fallire) o lasciare che lo strumento faccia il lavoro. Anche se lo strumento non farà un ottimo lavoro, non sarà ancora molto peggio (o anche meglio) rispetto a quello che un programmatore inesperto può fare quando progetta uno schema di database.

• Per piccoli progetti. Se sto facendo il mio sito personale che verrà utilizzato da me e alcuni dei miei amici, non c'è davvero bisogno di usare gli indici o scegliere con cura come i tavoli sono collegati insieme. Qualsiasi progetto (o la sua mancanza) funzionerà.

• Per i prototipi. L'obiettivo non è fare bene, ma fare velocemente. Se l'approccio code-first significa che puoi completare la funzione in sei ore anziché in sette, questo è un grande vantaggio. È qui che i generatori di codice (compresi quelli che producono codice scadente) o gli ORM in codice sono particolarmente preziosi: ti permettono di creare rapidamente una cosa e di concentrarti sui dettagli che contano (l'oggetto di un prototipo) estraendo i dettagli che non (lo schema del database).

La cosa fondamentale da comprendere è che il codice si riferisce a un caso a uso singolo mentre i dati possono riguardare diversi casi d'uso.

Quindi, sebbene il codice sia utile per un sistema semplice con pochi casi d'uso, qualsiasi cosa complessa con più casi d'uso avrà bisogno di un modello di dati decente per garantire che tutti i casi d'uso siano coperti.