cosa fanno i programmatori di database?

Per apprezzare davvero ciò che i programmatori di database devono veramente fare da soli - lasciami provare a spiegarlo in un altro modo.

Per gli informati che potrebbe sembrare nel mondo ideale i programmatori di applicazioni non lo fanno veramente tanto - prendono i requisiti e i processi come scritti dagli analisti di business e li traducono in codice quello che fanno i programmatori.

Naturalmente chiunque abbia una programmazione di esperienza 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 un certo numero di complicazioni

• I programmatori devono decidere come strutturare l'applicazione
• La traduzione dei requisiti in qualcosa che un computer comprende è spesso tutt'altro che banale.
• I programmatori devono essere consapevoli delle implicazioni sul rendimento di
• Man mano che i programmatori acquisiscono esperienza utilizzando la loro piattaforma di scelta, diventano più competenti, offrendo un codice di qualità superiore a un ritmo più rapido.

(Ovviamente questo è un elenco molto ridotto, sto solo cercando di raccogliere punti che hanno paralleli nello sviluppo del database)

Lo sviluppo del database è più o meno lo stesso: per i mal informati sembra piuttosto semplice, ma una volta che si è più coinvolti si diventa consapevoli 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 occuparsi 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ù abili 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 ...), lo sviluppo del database è spesso e le conseguenze di cadere di questi problemi sono molto gravi (es. perdita di dati o potenziale downtime per tutte le applicazioni che usano il database).

Penso che la cosa che fa pensare ai programmatori che non ci sia niente ("Un programmatore non può farlo?") è che c'è molta sovrapposizione tra i ruoli, e richiedono set di abilità simili - I Non ho dubbi sul fatto che chiunque abbia la capacità di essere un buon sviluppatore ha anche la capacità di essere un buon programmatore di database con il tempo e l'esperienza, ma nessuno dovrebbe sottovalutare il valore di un esperto di database esperto.

I programmatori di database fanno molte cose. Per prima cosa progettano la struttura del database in modo che funzioni correttamente con il numero di record attesi. Le strutture di progettazione che funzionano correttamente per poche migliaia di record possono rendere inutilizzabile un database a pochi milioni di record. Devono anche assicurarsi che i dati mantengano la loro integrità nel tempo e che i dati siano al sicuro da modifiche o furti non autorizzati. Devono capire chiaramente la normalizzazione e quando denormalizzare e perché. Devono capire le prestazioni e come garantire l'integrità dei dati. Devono capire la sicurezza e come impedire che i dati vengano rubati o modificati in modo pericoloso.

Eseguono le query di ottimizzazione. Ho cambiato le query che richiedono alcuni minuti per essere eseguiti fino a millsecondi. Ho cambiato un processo che ha impiegato oltre 24 ore per funzionare a meno di 30 minuti. Progettano e mantengono strutture di indicizzazione che bilanciano la velocità degli inserti rispetto alla velocità di selezione.

Scrivono query complesse che segnalano in particolare le query. Personalmente ho scritto query lunghe oltre 1000 righe a causa della complessità del requisito. Loro dovevano ancora e correvano rapidamente.

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

Devono determinare come refactoring come cambiano i requisiti del database senza danneggiare i 100.000.000 di record che hanno già e senza interrompere completamente l'utilizzo del database. I databs di grandi dimensioni possono coinvolgere migliaia di tabelle e 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 i modi per controllare i dati per ragioni normative e di recupero. Quindi progettano modi per recuperare i dati da quelle tabelle di controllo. Esaminano i problemi con i dati per scoprire se il problema proveniva da un errore nel processo di importazione, un file non valido fornito da altri o un cattivo inserimento / aggiornamento dall'applicazione o da accessi non autorizzati. Trovano il modo di correggere i dati errati quando i programmatori dell'applicazione lasciano un buco agli attacchi degli hacker.

Spesso sono coinvolti nelle conversioni di dati da un sistema a un nuovo sistema. A volte ciò comporta lo spostamento 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 di database potrebbe non avere alcun controllo sulle diverse strutture di dati.

Ho internato come programmatore di database per i dati di produzione di un wafer di 24 ore alla fine degli anni '90. Non so quanto fossero tipiche le mie mansioni, ma la parte più importante per me era quando era necessaria una modifica alla codifica o allo schema del campo, dovevo assicurarmi che il cambiamento fosse senza soluzione di continuità con la produzione. Essenzialmente, 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.

Questo è stato molto più complicato di quanto avessi previsto. Gli script di conversione e il software client dovevano essere accuratamente testati. Spesso due gruppi di dati semanticamente identici ma incompatibili dovevano essere mantenuti in sincronizzazione fino a quando tutti non erano passati. A volte era necessario effettuare il passaggio in più fasi attentamente pianificate per renderlo senza soluzione di continuità. Non era raro prepararsi per settimane a 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 facile. Non sono sorpreso che molte persone non sappiano davvero cosa fanno.

Questo è piuttosto semplice. Se hai sentito parlare del pattern MVC dovresti conoscere la differenza tra controller e modelli. Ad esempio, se stai scrivendo un ERP, immagina che nel tuo controller dici "retrieveCashFlow" al tuo modello e il tuo modello chiama un programma memorizzato nel database. Questo programma memorizzato si prende cura di ogni join, filtraggio, ordinamento e così via e si ottengono i dati elaborati. Nel tuo controller devi solo far saltare le cose insieme.

Se hai dubbi sulle stored procedure, dai un'occhiata a questo: perché utilizzare stored procedure?

In poche parole: gli sviluppatori di database scrivono programmi memorizzati (procedure e funzioni) per la tua applicazione per occuparsi della M in MVC (o delle logiche di business se non usi mvc).

Oracle non è solo un database ma un ambiente di programmazione completo, inclusi moduli e progettisti di report. Come programmatore Oracle, si programmano applicazioni utente complete. La codifica del database a cui fai riferimento verrebbe spesso eseguita dagli specialisti Database Adminstrators (DBA).

Penso che Sybase 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 struttura di progettazione / strutture di esecuzione.

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

• Progettazione, questo include la creazione (o meglio la definizione delle relazioni) delle tabelle
• Ottimizzazione, impostazione degli indici appropriati, scelta delle chiavi, scelta dei giusti tipi di dati
• Funzioni, scrivendo utili funzioni da utilizzare nelle query
• Procedure, scrivendo una logica applicativa strettamente accoppiata al livello del database.
• Creazione di funzioni di trigger per rispondere agli eventi
• Specifiche di produzione 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 di dati

Dai un'occhiata a questo elenco delle responsabilità