I programmatori esperti dovrebbero conoscere le query del database? [chiuso]

Ci sono così tanti programmatori là fuori che sono anche esperti nella scrittura di query e nella progettazione di database.

Questo dovrebbe essere un requisito fondamentale per essere un programmatore esperto o un ingegnere del software?

Sebbene ci siano molte somiglianze nel modo in cui vengono sviluppate le query e i codici, la mia opinione personale è che le query sembrano avere una struttura diversa rispetto al codice e può essere difficile padroneggiare entrambi contemporaneamente a causa dei diversi approcci.

Il fatto che la scrittura di query di database debba essere un requisito fondamentale dipende dal lavoro, ma i database relazionali sono onnipresenti nella tecnologia attuale.

Quindi, se incontrassi un programmatore che non sapeva come scrivere le query del database, mi aspetterei una di queste due cose:

1. Sono generalmente inesperti.
2. Sono altamente specializzati in un altro campo (ad esempio i sistemi integrati) e non hanno mai avuto bisogno di impararlo.

Le query del database sono sostanzialmente diverse dai linguaggi di programmazione più standard. Sono algebrici e destinati a operare su dati relazionali, mentre C # o Java sono imperativi e operano su dischi, memoria, input dell'utente, ecc. Anche i linguaggi funzionali come LISP o Haskell che hanno una forma più algebrica sono meno orientati ai dati relazionali.

EDIT: Come è stato sottolineato nei commenti da me e da altri, ci sono alcuni motivi validi per cui uno sviluppatore esperto potrebbe non conoscere bene le query del database:

• Il loro team ha utilizzato ORM / NoSQL
• Il loro team aveva programmatori DB
• La complessità dell'applicazione era nella logica aziendale e le query del DB erano banali
• Il loro team ha ripartito il lavoro in modo tale che alcuni programmatori non scrivessero query

Sebbene validi, questi avvertimenti non sono ragioni convincenti per cui uno sviluppatore esperto non conoscerebbe le query del database. Se non altamente specializzato, un programmatore dovrebbe avere familiarità con i database relazionali.

In sintesi, gli sviluppatori più esperti dovrebbero conoscere le query del database .

Qualsiasi ingegnere del software dovrebbe avere una conoscenza di base dei database e di come archiviare e recuperare i dati usando SQL, almeno al livello in cui hanno una comprensione di ciò che può essere usato (e con ciò includerei una comprensione di chiavi, viste , stored procedure e trigger).

Non tutti gli ingegneri del software devono essere esperti e il livello di esperienza richiesto dipende dal tipo di software su cui si concentrano. Software, driver hardware e sistemi operativi incorporati raramente utilizzano SQL, ma il software applicativo (sia esso web o desktop o basato su servizi / daemon) utilizza continuamente database.

Esistono alcune aree di competenza (ad esempio sistemi integrati) in cui non è necessaria la conoscenza del database. Ma la maggior parte delle applicazioni aziendali utilizza un database di qualche tipo e se non si capisce perfettamente come utilizzarlo correttamente, è possibile creare un pasticcio di prestazioni che è estremamente difficile da risolvere. I database di refactoring possono essere un processo complesso e difficile e molti posti scelgono di non risolvere i problemi strutturali a causa di quella difficoltà e di scavare più a fondo in un buco. Se hai conoscenza del database, la progettazione è molto più semplice e molto più probabile che funzioni bene nel tempo.

Gli ORM non sostituiscono la conoscenza del database. Chiunque ne usi uno senza conoscere le basi della query e della progettazione del database è condannato a disporre di un database scarsamente performante e mal progettato che influirà sulla capacità a lungo raggio dell'applicazione di gestire il carico. Gli ORM nelle mani di qualcuno che sa cosa sta facendo vanno bene; nelle mani di persone che non possono preoccuparsi di conoscere i database, di solito sono un disastro.

Se avessi un progetto con un back-end del database, lo specialista del database sarebbe il secondo sviluppatore che assumerei (dopo lo sviluppatore dell'applicazione iniziale). I database non sono generalmente usa e getta, i dati saranno ancora lì quasi nella stessa forma 20 anni dopo, è utile avere esperienza nelle fasi iniziali.

I progetti spesso finiscono nei guai perché non assumono queste persone fino a quando il database non ha 100.000.000 di record e funziona lentamente. Oppure danno la colpa allo strumento per essere cattivo (nessun SQL Server non è lento se si progetta correttamente) e non per la loro incompetenza progettuale.

La risposta politicamente corretta: dipende. La conoscenza di SQL non ha alcun valore se lo sviluppatore non lavora mai con database relazionali (e al giorno d'oggi delle applicazioni NoSQL, in realtà è abbastanza probabile).

In secondo luogo, quando esiste un DBA o un writer di query a tempo pieno (qualunque sia il titolo), anche la comprensione è di minore importanza.

È davvero importante solo se lo sviluppatore deve essere un tuttofare e c'è un requisito nei suoi progetti per l'utilizzo di un database relazionale (ad esempio in applicazioni Web vecchio stile o per la connessione con database esistenti)

La mia opinione personale: No. Uno sviluppatore di software esperto dovrebbe essere in grado di apprendere una nuova abilità (come SQL) se e quando è necessario, non "per impostazione predefinita". La flessibilità e la capacità di apprendere e comprendere è ciò che differenzia un buon sviluppatore da uno a posto. Si applica anche la regola del "martello d'oro": se si dispone di uno sviluppatore con una vasta conoscenza di SQL, è molto probabile che questo sviluppatore tirerà fuori lo strumento che conosce meglio - database relazionali - per tentare di risolvere ogni problema, mentre non ha necessariamente per essere la soluzione migliore. Naturalmente, questo vale anche per i sostenitori di NoSQL,;).

Scegliere lo strumento giusto per il lavoro giusto è ciò che un programmatore esperto dovrebbe sapere.

Dai un'occhiata a questa introduzione di Wikipedia alla programmazione per computer:

La programmazione informatica (spesso abbreviata in programmazione o codifica) è il processo di progettazione, scrittura, test, debug / risoluzione dei problemi e mantenimento del codice sorgente dei programmi per computer. Questo codice sorgente è scritto in un linguaggio di programmazione. Lo scopo della programmazione è quello di creare un programma che mostri un determinato comportamento desiderato.

Le query del database hanno le loro lingue, possono essere progettate, testate, debbuged e mantenute. Lo scopo di una query nel database è di consentirti di ottenere le informazioni di cui hai bisogno, nel modo in cui ne hai bisogno.

Quindi penso che stia programmando, sicuramente.

Un buon ingegnere informatico con esperienza in applicazioni aziendali e commerciali (EDIT: in particolare in progetti che utilizzano un RDBMS) dovrebbe avere una conoscenza approfondita della scrittura di query di database relazionali nel formato standard. Inoltre, dovrebbero essere in grado di comprendere schemi complessi e proporre progetti di schemi di complessità almeno moderata.

La progettazione di schemi estremamente avanzati o complicati dovrebbe essere il regno di un modellatore di dati o di un architetto funzionale.

Ciò non significa che neanche i programmatori di database abbiano un posto. Le procedure complesse memorizzate, le query complesse ed efficienti e la progettazione e l'architettura del software a livello di database incentrate sugli strumenti e le offerte unici di un singolo fornitore di database (ad es. Oracle, MySQL, SQLServer, ecc ...) dovrebbero essere lasciati nel migliore dei modi al software professionale ingegneri che hanno esperienza con queste offerte altamente specializzate e complicate.

La stragrande maggioranza dei sistemi aziendali e aziendali, tuttavia, secondo me non giustifica la necessità di modellatori di dati e programmatori di database specializzati, ma ho già lavorato a progetti di questo tipo che hanno beneficiato enormemente della conoscenza e dell'esperienza che queste persone hanno portato al tavolo.

Altri hanno già risposto alla tua domanda sulle query del database.

Il design del database è un tipo particolare di design. Non è difficile da imparare, ma il tipico progettista di database non ha molte opportunità di progettare un database.

Il posto in cui lavoro ora ha lo stesso design del database che aveva nel 1970. Abbiamo spostato il database da IDMS a DB2, ma è lo stesso design del database di rete. Ho avuto l'opportunità di creare 5 nuove tabelle DB2 nei 9 anni in cui ho lavorato qui.

Ho il sospetto che ci siano pochissimi posti di lavoro con un progettista di database dedicato. Quindi, concludo che la progettazione del database è considerata parte del repertorio di un analista senior.

Sono francamente sorpreso dal fatto che così tanti di noi pensino che ogni sviluppo ruota attorno a un database e ad un database SQL.

Altri hanno menzionato i molti modi in cui possiamo evitare la nitidezza di SQL nei nostri lavori, anche quando stiamo lavorando (indirettamente) con database, ma per quanto riguarda tutti gli sviluppatori che scrivono il firmware per i 101 prodotti elettrici che ognuno di noi possedere? E i ragazzi specializzati nel monitoraggio in tempo reale?

Suggerirei che la maggior parte degli sviluppatori di oggi disporrà di competenze SQL a vari livelli, ma è ben lungi dall'essere un barometro delle loro capacità.

Penso che tu sopravvaluti l'importanza dei database nel software.

Molte classi di applicazione non sono incentrate sul database.

Abbiamo bisogno di un DBMS negli elaboratori di testi e negli editor di immagini adesso? Che dire del riconoscimento vocale e dei sistemi di visione artificiale contengono molte query sul database?

E che dire degli editor video lineari e dei motori fisici dei videogiochi?

Mi aspetto che uno sviluppatore generalista abbia almeno una consapevolezza delle tecnologie di database (relazionali o meno) e sia in grado di discutere i vantaggi e gli svantaggi dell'utilizzo di queste. Altrimenti, avrei paura che tutto ciò che sanno fare sia trasferire i dati in file flat.

Non penso che la scrittura di query dovrebbe essere un requisito fondamentale per i programmatori. Detto ciò, ritengo che un programmatore in grado di scrivere query e progettare database sarebbe più prezioso per un'organizzazione.

Tuttavia, se questo programmatore può scrivere solo query di tipo "select * from tblxxxx" non considererei questo programmatore un esperto. Allo stesso modo, se il database progettato da questo programmatore inserisce relazioni uno-a-molti in una tabella anziché in due tabelle, non considererei questo programmatore un esperto.

Ecco come lo spiego a persone non IT. I professionisti IT sono specializzati in alcune aree simili a come i carpentieri, gli elettricisti e gli idraulici si specializzano in settori rispettati. Tendono a sovrapporre alcune delle competenze ma non sono esperti in tutti i settori. Un elettricista può svolgere semplici compiti di carpenteria con sicurezza ma non promette nulla di buono nel tentativo di affrontare strutture complesse.

Allo stesso modo, un programmatore può e deve sapere come scrivere o manipolare semplici query e progetti di database ma non ci si aspetta che progettino una struttura di dati complessa.

Guardandosi intorno nel nostro dipartimento, dipende:

• I nostri sviluppatori desktop / web / server . Almeno richiesto di scrivere istruzioni crud di base o avanzate a seconda della loro specialità. Per l'ottimizzazione abbiamo alcuni amministratori DB specializzati.
• I nostri programmatori integrati . Parecchi non hanno mai superato "select * from mytable". Tuttavia, ciò è cambiato anche in questi ultimi mesi con l'introduzione di sqllite nei loro progetti.