È compito dei programmatori progettare il database?

Sono stato programmatore negli ultimi sei anni. Durante la mia carriera, ho lavorato su molte applicazioni web.

Il più delle volte, quando era necessario un database, ci veniva dato (i programmatori) o avevamo un database legacy su cui lavorare. Altrimenti, dovevamo creare e progettare il database da soli, il che non era poi così difficile.

Ma, come programmatori, dovremmo creare l'intero database da zero quando dobbiamo costruire una nuova applicazione in cui i dati sono così importanti e hanno requisiti disordinati con un modello di dati complesso?

Non è nell'interesse dell'app e dell'azienda farla fare da un esperto?

Non sto cercando di scappare dalla progettazione del database, ma è una cosa che è così importante da ottenere nel modo giusto.

Prima di tutto, è il tuo lavoro se il project manager te lo dice. Le aziende più piccole spesso non dispongono di esperti DB a tempo pieno. Non c'è (e non dovrebbe esserci) una chiara distinzione tra sviluppatori ed esperti di DB: qualsiasi buon sviluppatore avrà una notevole conoscenza dei DB e qualsiasi buon DBA saprà come codificare, almeno nella lingua del DB per le procedure memorizzate .

Mentre il design del DB è una parte piuttosto centrale di un'applicazione, non è più importante "ottenere il giusto" rispetto ad altre parti centrali da cui dipenderà molto altro codice.

E proprio come il codice, l'idea che tu abbia qualche super esperto a sederti e pensare duro per una settimana e poi scrivere il design perfetto che non dovrà mai cambiare è un'illusione. La progettazione del DB può e cambierà durante lo sviluppo dell'applicazione.

È quindi effettivamente utile avere il DB progettato da un programmatore (che capisce bene i DB), perché allora hai qualcuno che conosce entrambe le parti. È sicuramente meglio che averlo fatto da qualcuno che capisce solo i DB e non ha nulla a che fare con il resto del lavoro di sviluppo.

È comune per i programmatori creare il database. Molto comune. Sfortunatamente molti programmatori non hanno esperienza con il DB. Non capiscono come riferire contro i big data, i concetti di data mart, schemi a stella, ecc. Alcuni non capiscono nemmeno le basi della normalizzazione.

Se un uomo ha le competenze per fare tutto a livello di esperti, si ottiene un ottimo prodotto. Un esercito di un solo uomo può fare ciò che una squadra di 10 uomini può fare in una frazione del tempo con una qualità 1000 volte superiore. Non è un'esagerazione.

È nel migliore interesse per il programmatore farlo (meno persone), supponendo che il programmatore sappia cosa sta facendo. Naturalmente ci sono anche migliaia di fallimenti da segnalare.

È una domanda interessante - c'è una forte argomentazione secondo cui gli sviluppatori più decenti dovrebbero capire come strutturare correttamente un database relazionale, vale a dire che dovrebbero essere in grado di produrre uno schema normalizzato e - in base all'esperienza e ai modelli comuni - di rendere ragionevole decisioni su come i dati dovrebbero essere strutturati archiviati (per me è per lo più evidente, ma so che non tutti lo vedono in questo modo).

Inoltre, se si esamina prima Entity Framework Code che suggerisce che lo stesso pensiero che va alla costruzione di un modello di dati di basso livello produrrà uno schema ragionevole - o almeno suggerirà uno.

Quindi no, non penso particolarmente che tu abbia bisogno di un esperto di database per progettare uno schema di database - almeno non per database di piccole e medie dimensioni (che sono le cose su cui ho lavorato).

Il problema è che progettare uno schema valido (o almeno adeguato) non è l'intera storia, specialmente se il database deve essere ridimensionato. Mi sembra che il "valore aggiunto" apportato da un DBA sia quello di ottenere le cose diverse dallo schema di base giusto: indici, configurazione dell'archiviazione, manutenzione del database (controllo delle dimensioni dei file, ricostruzione degli indici, ecc.), Più intelligente con utenti e ruoli e così via e così via.

Un buon programmatore dovrebbe portare un portafoglio diversificato di competenze - dovrebbe essere più di un programmatore [inserire lingua di scelta] e includerei la comprensione dei database in quel portafoglio.

Penso che la capacità di progettare un ragionevole database relazionale sia essenzialmente una necessità per i programmatori non junior.

Detto questo, in particolare per le applicazioni di grandi dimensioni, è fondamentale ottenere il database "giusto" la prima volta (schema, indicizzazione, ecc.). Se la società ha accesso a un DBA qualificato, tale compito dovrebbe rientrare nel suo piatto; in generale saranno più qualificati. Potenzialmente la revisione / discussione dovrebbe essere fatta con lo sviluppatore principale che accederà e lavorerà con il database sul lato client in modo che non ci siano sorprese. Se non è presente alcun DBA, il programmatore progetta il database.

Vedo due domande qui:

• Gli sviluppatori di database dovrebbero modellare la logica aziendale?
• Devo sapere come conservare i dati nel database?

Logica di business

• La logica aziendale non vive in un database. È un modello concettuale che deve essere indipendente da altri livelli all'interno del sistema.

• Puoi sempre sostituire un database con un altro, oppure potresti persino decidere di utilizzare una soluzione NoSQL per affrontare potenziali problemi di prestazioni.

• Gli sviluppatori di database possono essere coinvolti durante il processo di modellazione, ma normalmente ciò viene fatto da persone con una completa comprensione di un dominio problematico. Nella nostra organizzazione questo viene fatto dagli sviluppatori lato server.

• Molti pensano che il database sia il fondamento della tua applicazione. Crea fondamenta scadenti e il sistema cadrà. Non sono d'accordo con questo. Vedo il database come supporto di archiviazione che può essere sempre sostituito.

Dati persistenti

• Dovresti sapere come conservare i dati su diversi supporti di archiviazione, comprese le soluzioni SQL e NoSQL.

• Il livello di esperienza richiesto varierà con le dimensioni del sistema su cui stai lavorando.

• Le piccole aziende si aspetterebbero che tu abbia questa conoscenza, quando le aziende più grandi assumerebbero normalmente esperti per soddisfare i requisiti di prestazioni, scalabilità e sicurezza.

Riassumere:

• Il modello di dominio è una base del tuo sistema, non del database.

• Se lavori per una piccola azienda su un progetto relativamente piccolo, probabilmente dovresti progettare tu stesso il database.

• Se lavori per una grande azienda su un sistema aziendale, probabilmente ha più senso passare il lavoro agli esperti del dominio.