cosa fanno i programmatori di database?

Ogni volta che leggo dei programmatori Oracle ecc., Mi confondo. Non so cosa facciano esattamente.

Da quanto ho capito, i programmatori di applicazioni devono sviluppare le funzionalità di base. Le librerie che usano potrebbero aiutare nello sviluppo della GUI o nella connettività del database, ma la funzionalità che rende quell'applicazione quell'applicazione deve essere programmata e che rende ogni applicazione diversa (ben alcune potrebbero essere versioni ottimizzate di altre).

In questa relazione, la programmazione del database non sta fondamentalmente creando una tabella e queste tabelle non vengono elaborate in risposta a istruzioni SQL emesse da un'applicazione che di solito è il front-end? Quindi la creazione di tavoli è così importante?

Per apprezzare davvero quali programmatori di database devi davvero provare, lasciami provare a spiegarlo in un altro modo.

Per i mal informati potrebbe sembrare che nel mondo ideale i programmatori di applicazioni non facciano molto: prendono i requisiti e i processi scritti dagli analisti aziendali e li traducono in codice che fa offerte ai programmatori.

Naturalmente chiunque abbia esperienza nella programmazione saprà che non è così che funziona - ignorando per il momento il fatto che i requisiti non specificano mai il comportamento dell'applicazione fino ai minimi dettagli, ci sono una serie di complicazioni

• I programmatori devono decidere come strutturare l'applicazione
• Tradurre i requisiti in qualcosa che un computer capisce è spesso tutt'altro che banale.
• I programmatori devono essere consapevoli delle implicazioni delle prestazioni di
• Man mano che i programmatori acquisiscono esperienza utilizzando la loro piattaforma preferita, diventano più competenti, offrendo un codice di qualità superiore a una velocità maggiore.

(Naturalmente questo è un elenco notevolmente ridotto, sto solo cercando di raccogliere punti che hanno parallelismi nello sviluppo del database)

Bene, lo sviluppo del database è più o meno lo stesso - per i mal informati sembra piuttosto semplice, ma una volta che sei più coinvolto ti accorgi delle complicazioni specifiche dello sviluppo del database:

• Decidono come strutturare il database
• Spesso le query più complesse possono essere tutt'altro che banali da tradurre dai requisiti
• Gli sviluppatori di database devono preoccuparsi delle prestazioni del database
• Devono anche preoccuparsi di mantenere l'integrità e la disponibilità dei dati
• E proprio come gli sviluppatori, i programmatori di database diventano più competenti in tutto ciò che fanno man mano che diventano più esperti.

Proprio come lo sviluppo di applicazioni è pieno di insidie ​​nascoste (problemi di threading ecc ...), così è lo sviluppo del database, e spesso le conseguenze della caduta di questi problemi sono molto gravi (ad es. Perdita di dati o potenzialmente tempi di inattività per tutte le applicazioni che utilizzano il database) .

Penso che la cosa che fa pensare ai programmatori che non ci sia nulla ("Un programmatore non può farlo?") È che ci sono molte sovrapposizioni tra i ruoli e richiedono set di abilità simili - Ho senza dubbio che chiunque abbia la capacità di essere un buon sviluppatore ha anche la capacità di essere un buon programmatore di database, dato il tempo e l'esperienza, tuttavia nessuno dovrebbe sottovalutare il valore di un esperto di database con esperienza.

I programmatori di database fanno molte cose. Innanzitutto progettano la struttura del database in modo che funzioni correttamente con il numero di record previsti. Le strutture di progettazione che funzionano correttamente per alcune migliaia di record possono rendere inutilizzabile un database in pochi milioni di record. Devono inoltre assicurarsi che i dati mantengano la loro integrità nel tempo e che i dati siano protetti da modifiche o furti non autorizzati. Devono comprendere a fondo la normalizzazione e quando denormalizzare e perché. Devono comprendere le prestazioni e come garantire l'integrità dei dati. Devono comprendere la sicurezza e come impedire che i dati vengano rubati o modificati in modo dannoso.

Ottimizzano le query. Ho modificato le query che richiedono minuti per l'esecuzione in millsecondi. Ho modificato un processo che ha richiesto più di 24 ore per funzionare in meno di 30 minuti. Progettano e mantengono strutture di indicizzazione in grado di bilanciare la velocità degli inserti con la velocità delle selezioni.

Scrivono query complesse, in particolare quelle di reportistica. Personalmente ho scritto query lunghe oltre 1000 righe a causa della complessità del requisito. Dovevano ancora e correvano in fretta.

Creano data warehouse e i relativi processi ETL per supportarli. Spesso hanno bisogno di scrivere processi per portare i dati da altre fonti e devono capire come mappare i campi da alcuni database dei loro clienti ai loro e questi non sono mai una corrispondenza ravvicinata nel tipo di dati, dimensione dei dati, campi obbligatori, valori di ricerca, eccetera.

Devono determinare come refactoring quando cambiano i requisiti del database senza danneggiare i 100.000.000 di record che già possiedono e senza interrompere completamente l'uso del database. I database di grandi dimensioni possono coinvolgere migliaia di tabelle, processi memorizzati e funzioni definite dall'utente. Comprendere una tale struttura richiede tempo e abilità, così come capire cosa sarà influenzato dai cambiamenti e come.

Progettano modi per controllare i dati per motivi normativi e di recupero. Quindi progettano modi per recuperare i dati da tali tabelle di controllo. Esse ricercano problemi con i dati per scoprire se il problema derivava da un bug nel processo di importazione, da un file errato fornito da altri o da un inserimento / aggiornamento errato dall'applicazione o da un accesso non autorizzato. Trovano il modo di correggere i dati errati quando i programmatori delle applicazioni lasciavano un buco aperto agli attacchi degli hacker.

Spesso sono coinvolti nelle conversioni di dati da un sistema a un nuovo sistema. A volte ciò comporta il trasferimento di dati da un prodotto COTS a uno nuovo che l'azienda ha appena acquistato. Come le importazioni descritte in precedenza, si tratta di processi complessi che possono richiedere mesi per pianificare ed eseguire e che richiedono test approfonditi. A differenza delle importazioni, il programmatore del database potrebbe non avere alcun controllo sulle diverse strutture di dati.

Alla fine degli anni '90 ho lavorato come programmatore di database per i dati di produzione di un fab wafer di 24 ore. Non so quanto fossero tipici i miei doveri, ma la parte più grande per me è stata quando era necessaria una modifica alla codifica o allo schema del campo, dovevo assicurarmi che la modifica fosse perfetta per la produzione. In sostanza, ciò significava che avrei detto loro di aggiornare la loro applicazione client, cosa che avrebbero fatto in un momento conveniente per loro, e ci si aspettava che tornasse immediatamente con le nuove modifiche.

È stato molto più coinvolto di quanto mi aspettassi. Gli script di conversione e il software client dovevano essere testati a fondo. Spesso due set di dati semanticamente identici ma incompatibili dovevano essere mantenuti in sincronia fino a quando tutti non venivano commutati. A volte era necessario effettuare il passaggio in più fasi, attentamente pianificate per renderlo senza interruzioni. Non era raro prepararsi per settimane per una commutazione avvenuta essenzialmente istantaneamente.

Se un programmatore di database sta facendo bene il suo lavoro, sembrerà agli osservatori che il suo lavoro sia molto semplice. Non mi sorprende che molte persone non sappiano davvero cosa fanno.

Questo è piuttosto semplice. Se hai sentito parlare del modello MVC, dovresti conoscere la differenza tra controller e modelli. Ad esempio, se stai scrivendo un ERP, immagina che nel tuo controller tu dica semplicemente "retrieveCashFlow" al tuo modello e che il tuo modello chiami un programma memorizzato nel database. Questo programma memorizzato si occupa di ogni join, filtro, ordinamento e così via e si ottiene indietro i dati elaborati. Nel tuo controller devi solo mettere insieme le cose.

In caso di dubbi sulle procedure memorizzate, consultare questo: perché utilizzare le procedure memorizzate?

In poche parole: gli sviluppatori di database scrivono programmi memorizzati (procedure e funzioni) affinché l'applicazione si occupi della M in MVC (o delle logiche aziendali se non si utilizza mvc).

Oracle non è solo un database ma un ambiente di programmazione completo, inclusi moduli e progettisti di report. Come programmatore Oracle, programmi applicazioni utente complete. La codifica del database a cui fai riferimento viene spesso eseguita da amministratori di database specializzati (DBA).

Sybase penso che sia un altro con ambienti di programmazione simili.

Altri database possono limitarsi a "solo" consentire la definizione e l'esecuzione di report, mentre altri potrebbero non offrire alcuna forma o strutture di progettazione / esecuzione di report.

Direi che uno sviluppatore di database è responsabile di uno o più dei seguenti

• Design, questo include la creazione (o piuttosto la definizione di relazioni) tabelle
• Ottimizzazione, impostazione degli indici corretti, scelta delle chiavi, scelta dei giusti tipi di dati
• Funzioni, scrittura di funzioni utili da utilizzare nelle query
• Procedure, scrittura di logiche applicative strettamente collegate al livello del database.
• Creazione di funzioni trigger per rispondere agli eventi
• Produrre le specifiche di cui sopra.

A seconda del RDBMS in questione, potrebbe includere attività come

• Creazione di report e moduli
• Creazione di flussi per l'importazione / esportazione dei dati

Dai un'occhiata a questo elenco di responsabilità