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

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

Quindi, se avessi incontrato un programmatore che non sapeva come scrivere le query del database, mi aspetterei una delle seguenti due cose:

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

Le query sul database sono fondamentalmente diverse da altri linguaggi di programmazione 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 sono più algebrici nella forma sono meno orientati ai dati relazionali. / p>

EDIT: Come è stato sottolineato nei commenti da me e da altri, ci sono alcuni validi motivi 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 DB erano banali
• Il loro team ha suddiviso il lavoro in modo tale che alcuni programmatori non hanno scritto query

Sebbene validi, questi avvertimenti non sono motivi validi per cui uno sviluppatore esperto non conosce le query del database. A meno che non sia altamente specializzato, un programmatore dovrebbe avere familiarità con i database relazionali.

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

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

Non tutti i progettisti di software devono essere esperti e il livello di esperienza richiesto dipende molto dal tipo di software su cui si concentrano. Il software incorporato, i driver hardware e i sistemi operativi utilizzano raramente SQL, ma il software applicativo (sia esso web o desktop o servizio / demone basato) usa sempre i database.

Ci sono alcune aree di competenza (sistemi incorporati per esempio) in cui la conoscenza del database non è necessaria. Ma la maggior parte delle applicazioni aziendali utilizza un database di qualche tipo e se non capisci bene come usarlo correttamente, puoi creare un pasticcio delle prestazioni che è estremamente difficile da risolvere. I database di refactoring possono essere un processo complesso e difficile e molti luoghi preferiscono non risolvere i problemi strutturali a causa di questa difficoltà e solo 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 faccia uso senza conoscere le basi della query e della progettazione del database è destinato ad avere un database mal progettato e mal progettato che influirà sulla capacità a lungo raggio della propria applicazione di gestire il carico. Gli ORM nelle mani di qualcuno che sa cosa sta facendo stanno bene; nelle mani di persone che non possono essere disturbate a 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 eliminabili, ma i dati saranno ancora lì vicino allo stesso modulo 20 anni dopo, vale la pena di avere esperienza nelle fasi iniziali.

I progetti spesso finiscono nei guai perché non assumono queste persone finché il database non ha 100.000.000 di record e funziona lentamente. Oppure incolpano lo strumento di essere cattivo (nessun SQL Server non è lento se si progetta correttamente) e non la loro incompetenza di progettazione.

La risposta politicamente corretta: dipende. La conoscenza SQL non ha alcun valore se lo sviluppatore non lavora mai con i database relazionali (e in questo giorno ed età delle applicazioni NoSQL, in realtà è abbastanza probabile).

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

È molto importante solo se lo sviluppatore ha bisogno di essere un tuttofare e nei suoi progetti c'è un requisito per l'utilizzo di un database relazionale (ad esempio in applicazioni Web obsolete o in collegamento 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 "di default". La flessibilità e la capacità di apprendere e capire è, imho, ciò che differenzia un buon sviluppatore da quello giusto. La regola "golden hammer" vale anche - se hai uno sviluppatore con una profonda conoscenza di SQL, è molto probabile che questo sviluppatore tiri fuori lo strumento che conosce meglio - database relazionali - per tentare di risolvere ogni problema, mentre non necessariamente ha per essere la soluzione migliore. Naturalmente, questo vale anche per i sostenitori 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 del computer:

Computer programming (often shortened to programming or coding) is the process of designing, writing, testing, debugging / troubleshooting, and maintaining the source code of computer programs. This source code is written in a programming language. The purpose of programming is to create a program that exhibits a certain desired behavior.

Le query sul database hanno le loro lingue, potrebbero essere progettate, testate, sottoposte a manutenzione e mantenute. L'obiettivo di una query di database è consentire all'utente di ottenere le informazioni necessarie, nel modo in cui è necessario.

Quindi penso che sia la programmazione, definitivamente.

Un buon ingegnere del software con un background in applicazioni aziendali e aziendali (EDIT: in particolare nei 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 schemi di schemi di almeno moderata complessità.

La progettazione di uno schema estremamente avanzato o complicato dovrebbe essere il regno di un modellatore di dati o di un architetto funzionale.

Questo non significa neanche che i programmatori di database non abbiano una posizione. Le procedure memorizzate complesse, le query complesse ed efficienti e la progettazione e l'architettura del software di livello database incentrate sugli strumenti e le offerte esclusive di un singolo fornitore di database (ad esempio Oracle, MySQL, SQLServer, ecc.) Dovrebbero essere lasciate il più possibile possibile al software professionale ingegneri che hanno esperienza con questi offerrings altamente specializzati e complicati.

La stragrande maggioranza dei sistemi aziendali e aziendali, tuttavia, a mio avviso non giustifica la necessità di modellatori di dati e programmatori specializzati di database, ma ho già lavorato su tali progetti, GRANDIOSO ha beneficiato delle conoscenze e delle competenze che queste persone hanno apportato al tavolo.

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

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

Il luogo 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 nuovi tavoli DB2 nei 9 anni in cui ho lavorato qui.

Ho il sospetto che ci siano pochissimi posti di lavoro con un designer di database dedicato. Quindi, direi che il design del database è considerato parte del repertorio di un analista senior.

Sono abbastanza sinceramente sorpreso che così tanti di noi pensano che ogni sviluppo ruota intorno a un database e un database SQL.

Altri hanno menzionato i molti modi in cui possiamo evitare il nocciolo di SQL nei nostri lavori, anche quando lavoriamo (indirettamente) con i database, ma che dire di tutti gli sviluppatori che scrivono il firmware per i 101 prodotti elettrici ognuno di noi possiede? Che dire dei ragazzi specializzati nel monitoraggio in tempo reale?

Suggerirei che la maggior parte degli sviluppatori di oggi avrà competenze SQL in misura diversa, ma è ben lungi dall'essere un barometro delle loro capacità.

Penso che tu stia sopravvalutando l'importanza dei database nel software.

Molte classi di applicazioni non sono incentrate sul database.

Abbiamo bisogno di un DBMS nei word processor e negli editor di immagini ora? Per quanto riguarda i sistemi di riconoscimento vocale e di visione artificiale, questi contengono molte query di 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 di altro tipo) e sia in grado di discutere i pro e i contro dell'utilizzo di tali tecnologie. Altrimenti temo che tutto ciò che sanno fare sia inserire dati in file flat.

Non penso che la scrittura di query debba essere un requisito fondamentale per i programmatori. Detto questo, credo che un programmatore in grado di scrivere query e progettare database sia più prezioso per un'organizzazione.

Tuttavia, se questo programmatore può scrivere solo query "select * from tblxxxx", non considererei questo programmatore un esperto. Allo stesso modo, se il database progettato da questo programmatore pone le relazioni uno-a-molti in una tabella invece di 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 carpentieri, elettricisti e idraulici si specializzano in campi rispettati. Tendono a sovrapporsi ad alcune abilità ma non sono esperti in tutte le aree. Un elettricista può fare semplici lavori di carpenteria con sicurezza, ma non sarebbe di buon auspicio cercando 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 può aspettare che progettino una struttura dati complessa.

Guardarsi intorno nel nostro dipartimento, dipende:

• I nostri sviluppatori desktop / web / server . Almeno richiesto per scrivere le istruzioni di base in anticipo in base alla loro specialità. Per l'ottimizzazione abbiamo alcuni amministratori DB specializzati.
• I nostri programmatori incorporati . Alcuni non hanno mai superato "select * from mytable". Tuttavia, questo è cambiato anche in questi ultimi mesi con l'introduzione di sqllite ai loro progetti.