È compito dei programmatori progettare il database?

Prima di tutto, è il tuo lavoro se il project manager ti dice così. Le aziende più piccole spesso non hanno esperti di DB a tempo pieno. Non c'è (e non dovrebbe esserci) una chiara distinzione tra sviluppatori e esperti di DB in ogni caso - ogni buon sviluppatore avrà una notevole conoscenza dei DB, e ogni buon DBA saprà come codificare, almeno nella lingua del DB per le stored procedure .

Sebbene il design del DB sia una parte piuttosto centrale di un'applicazione, non è più importante "avere ragione" di altre parti centrali da cui dipenderà molto codice.

E proprio come il codice, l'idea di avere un super-esperto per sedersi e riflettere duramente per una settimana e poi scrivere il design perfetto che non avrà mai bisogno di cambiare è un'illusione. Il design del DB può e cambierà con lo sviluppo dell'applicazione.

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

È normale che i programmatori creino il database. Molto comune. Sfortunatamente molti programmatori non hanno esperienza con il DB. Non capiscono come denunciare 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 capacità per fare tutto a livello di esperti, diventa 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 1000 volte la qualità. Non un'esagerazione.

È nell'interesse del programmatore farlo (meno persone), assumendo che il programmatore sappia cosa sta facendo. Ovviamente ci sono anche migliaia di errori da segnalare.

È una domanda interessante - c'è una strong argomentazione secondo cui molti sviluppatori decenti dovrebbero capire come strutturare correttamente un database relazionale, vale a dire che dovrebbero essere in grado di produrre uno schema normalizzato e - basato su esperienza e modelli comuni - prendere decisioni ragionevoli su come archiviare i dati archiviati (per me è per lo più ovvio, ma so che non tutti la vedono in quel modo).

Inoltre, se si esamina il codice di Entity Framework, in primo luogo che suggerisce che lo stesso pensiero che va alla creazione di un modello di dati di basso livello produrrà uno schema ragionevole - o almeno un suggerimento in uno.

Quindi no, non penso particolarmente che sia necessario 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 la progettazione di uno schema buono (o almeno adeguato) non è l'intera storia, specialmente se il database non è in scala. Mi sembra che il "valore aggiunto" apportato da un DBA sia nell'ottenere le cose diverse dallo schema di base a destra: indici, configurazione dello storage, manutenzione del database (tenere sotto controllo le dimensioni dei file, ricostruzione degli indici, ecc.), Essere più intelligenti con utenti e ruoli e così via e così via.

Un buon programmatore dovrebbe portare un portfolio diversificato di competenze - dovrebbe essere più di un codificatore [insert langugage of choice] e includerei la comprensione dei database in quel portfolio.

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

Detto questo, in particolare per le applicazioni di grandi dimensioni, è fondamentale ottenere il database "correttamente" la prima volta (schema, indicizzazione, ecc.). Se la società ha accesso a un DBA qualificato, tale compito dovrebbe cadere sul 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 c'è un DBA, il programmatore progetta il database.

Vedo due domande qui:

• Gli sviluppatori di database dovrebbero modellare la business logic?
• Dovrei sapere come mantenere i dati nel database?

Business Logic

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

• È sempre possibile sostituire un database con un altro o addirittura decidere di utilizzare soluzioni NoSQL per affrontare potenziali problemi di prestazioni.

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

• Molti pensano che il database sia alla base della tua applicazione. Fai pessime basi 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 mantenere i dati su diversi supporti di memorizzazione, 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 aspettano che tu abbia questa conoscenza, quando le grandi aziende normalmente assumono esperti per soddisfare i requisiti di prestazioni, scalabilità e sicurezza.

Per riepilogare:

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

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

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