Les programmeurs expérimentés devraient-ils connaître les requêtes de base de données? [fermé]

35

Il y a tellement de programmeurs qui sont aussi des experts en rédaction de requêtes et en conception de bases de données.

Devrait-il s'agir d'une exigence essentielle pour être un programmeur expert ou un ingénieur en logiciel?

Bien qu'il existe de nombreuses similitudes dans la façon dont les requêtes et les codes sont développés, mon opinion personnelle est que les requêtes semblent avoir une structure différente de celle du code et il peut être difficile de maîtriser les deux simultanément, en raison d'approches différentes.

database query

— Shamim Hafiz
source

2

Qu'entendez-vous par "structure"? Si vous parlez de sémantique, saisir un nouveau type de sémantique ne devrait pas être un problème pour un " expert ". Par définition. OTOH, seuls quelques développeurs sont exposés aux bases de données et aux langages de requête, le reste d'entre nous s'en moque.

— SK-logic

3

Je pense que ceci est une hypothèse erronée: "Il y a tellement de programmeurs qui sont aussi des experts en rédaction de requêtes et en conception de bases de données." Il y a relativement peu de programmeurs experts dans ces domaines: DBA! = SE.

— Ashley

1

Est-il vraiment difficile d'écrire des requêtes de base de données?

— Captain Sensible

@CaptainShakespeare, cela peut devenir très difficile une fois les opérations CRUD passées. Ty fait parfois des reportages complexes. Et ensuite, examinez les requêtes de réglage des performances.

— HLGEM

69

La question de savoir si l'écriture d'une requête de base de données doit être une exigence essentielle dépend du travail, mais les bases de données relationnelles sont omniprésentes dans la technologie actuelle.

Donc, si je rencontrais un programmeur qui ne savait pas écrire des requêtes de base de données, je m'attendrais à l'une des deux choses suivantes:

Ils sont généralement inexpérimentés.
Ils sont hautement spécialisés dans un autre domaine (par exemple, les systèmes embarqués) et n’ont jamais eu besoin de l’apprendre.

Les requêtes de base de données sont fondamentalement différentes des langages de programmation plus standard. Ils sont algébriques et destinés à fonctionner sur des données relationnelles, alors que C # ou Java sont impératifs et fonctionnent sur des disques, de la mémoire, des entrées utilisateur, etc. Même les langages fonctionnels tels que LISP ou Haskell qui sont de forme plus algébrique sont moins orientés vers les données relationnelles.

EDIT: Comme cela a été souligné dans les commentaires de moi et d’autres, il existe certaines raisons valables pour lesquelles un développeur expérimenté ne connaît peut-être pas bien les requêtes de base de données:

Leur équipe a utilisé ORM / NoSQL
Leur équipe avait des programmeurs DB
La complexité de l'application se trouvait dans la logique métier et les requêtes dans la base de données étaient triviales.
Leur équipe a réparti le travail de sorte que certains programmeurs n’écrivent pas de requêtes.

Bien que valables, ces mises en garde ne constituent pas des raisons convaincantes pour lesquelles un développeur expérimenté ne connaît pas les requêtes de base de données. À moins d'être hautement spécialisé, un programmeur doit être familiarisé avec les bases de données relationnelles.

En résumé, les développeurs les plus expérimentés devraient connaître les requêtes de base de données .

— Matthew Rodatus
source

1

Donc, si quelqu'un a réalisé un projet non trivial utilisant Database, il devrait être familiarisé avec les requêtes, n'est-ce pas?

— Shamim Hafiz Le

3

@Shamim, je m'attendrais à ce que cette personne connaisse assez bien les requêtes, à moins que cette personne ne soit débutante ou débutante. Peut-être que cette personne n'a que quelques années d'expérience et était hébergée dans une équipe hautement spécialisée?

— maple_shaft

12

@Shamim Je m'y attendrais probablement . Ils pourraient toujours être un bon programmeur. Il est très difficile de répondre à des questions comme celle-ci, car elles comportent de nombreuses réserves: peut-être que l'équipe avait un programmeur de bases de données; peut-être que la non-rivalité de l'application se trouvait dans la logique métier et que les requêtes de la base de données étaient triviales; peut-être ont-ils réparti le travail de manière à ce que votre programmeur ne traite pas les requêtes; etc.

— Matthew Rodatus

4

Mon équipe de développement a des programmeurs PL / SQL dédiés dans le cadre du projet. Ainsi, alors que les programmeurs .Net peuvent faire des requêtes simples, ils sont là pour les examiner et développer les requêtes plus complexes. De plus, avec la prolifération d'ORM (et de NOSQL), pourquoi pensez-vous que les développeurs non-SQL doivent connaître des requêtes complexes?

— Softveda

2

@ Matthew Rodatus: J'ai travaillé dans des endroits dotés de bibliothèques qui géraient les requêtes. Il serait donc théoriquement possible d'y travailler sans comprendre le simple langage SQL. Je crois que tous les développeurs étaient compétents dans la pratique.

— David Thornley

23

Tout ingénieur en logiciel devrait avoir une connaissance de base des bases de données et savoir comment stocker et récupérer des données à l’aide de SQL, au moins jusqu'au niveau où ils comprennent ce à quoi cela peut servir (et avec cela, j’inclue une compréhension des clés, des vues , procédures stockées et déclencheurs).

Tous les ingénieurs en logiciels ne doivent pas nécessairement être des experts et le niveau d’expertise requis dépend vraiment du type de logiciel sur lequel ils se concentrent. Les logiciels intégrés, les pilotes matériels et les systèmes d'exploitation utilisent rarement SQL, mais les logiciels d'application (qu'ils soient basés sur le Web, les ordinateurs de bureau ou les services / démons) utilisent constamment des bases de données.

— Wolfgangsz
source

1

Heureusement, de nos jours, il est parfaitement possible de faire des applications sans aucun SGBDR. La plupart des tâches n'en ont pas besoin ou ne peuvent tout simplement pas être correctement associées à un modèle relationnel. Il y a des tonnes d'options de stockage non relationnelles disponibles.

— SK-logic le

8

Cela résume aussi mon opinion. Expert? Pas de connaissances? Oui.

— Wayne Molina

2

@ SK-logic, Quels types d'options pensez-vous rendre les bases de données relationnelles non pertinentes? Le stockage de données est trop spécialisé pour que l'analyse soit utile dans un système transactionnel. Et ne me lancez pas sur tout ce qui ne va pas avec OODBMS.

— maple_shaft

1

@maple_shaft, il existe de nombreuses solutions de stockage spécialisées, orientées vers le domaine. Les SGBDR essaient d'être génériques et échouent mal en cela. Dans certains cas, même les anciens SGBD hiérarchiques sont bien meilleurs que les systèmes relationnels.

— SK-logic le

6

Tous les logiciels de bureau n'utilisent pas de bases de données, soyez donc prudent lorsque vous dites que cela se produit tout le temps.

— Adam Lear

18

Il existe des domaines d’expertise (systèmes intégrés, par exemple) où la connaissance des bases de données n’est pas nécessaire. Cependant, la plupart des applications professionnelles utilisent une base de données. Si vous ne comprenez pas bien comment l'utiliser correctement, vous pouvez créer un gâchis de performances extrêmement difficile à réparer. La refactorisation des bases de données peut être un processus complexe et difficile et de nombreux endroits choisissent de ne pas résoudre les problèmes structurels en raison de cette difficulté et de s'enfoncer davantage dans un trou. Si vous avez des connaissances en base de données, la conception est beaucoup plus facile et plus susceptible de bien fonctionner avec le temps.

Les ORM ne remplacent pas la connaissance de la base de données. Quiconque en utilise une sans connaître les bases de la conception et de l’interrogation de base de données est condamné à avoir une base de données mal conçue et peu performante qui affectera la capacité à long terme de votre application à gérer la charge. Les ORM entre les mains de quelqu'un qui sait ce qu'il fait vont bien; dans les mains de personnes qui ne peuvent pas être dérangées pour en apprendre davantage sur les bases de données, elles sont généralement une catastrophe.

Si j'avais un projet avec un backend de base de données, le spécialiste de la base de données serait le deuxième développeur que j'embaucherais (après le développeur de l'application initiale). Les bases de données ne sont généralement pas éblouissantes, car elles y resteront pratiquement sous la même forme vingt ans plus tard, il est rentable de disposer d'une expertise dès le début.

Les projets rencontrent souvent des problèmes parce qu'ils n'engagent pas ces personnes tant que la base de données ne contient pas 100 000 000 d'enregistrements et ne fonctionne que très lentement. Ou ils accusent l'outil d'être mauvais (SQL Server n'est pas lent si vous concevez correctement), pas d'incompétence de conception.

— HLGEM
source

4

+1 pour mentionner que la présence d'un ORM ne remplace pas le besoin de connaître SQL (ou les facteurs sous-jacents dans le type de base de données utilisé).

— RHSeeger

4

+1 et j'aimerais pouvoir vous en donner 100 de plus! Je connais cette corrélation! = Causalité, mais il m'est tout à fait évident que les développeurs d’applications les plus efficaces avec lesquels j’ai travaillé avaient une connaissance approfondie de la rédaction d’une requête SELECT standard. Je devrais pouvoir donner à un bon développeur un modèle de données et une "question" sur les données. Cette personne devrait éventuellement être capable d'écrire une requête qui "répond" à ma question.

— maple_shaft

1

+1, totalement d'accord. Je n'achète pas l'explication selon laquelle "nous utilisons ORM" ou "nous avons des programmeurs dédiés à cela". Si quelqu'un est vraiment expérimenté , il aurait rempli le rôle de développeur de base de données à un moment donné. C'est ce que l'expérience est.

— GrandmasterB

15

La réponse politiquement correcte: ça dépend. La connaissance de SQL n'a aucune valeur si le développeur ne travaille jamais avec des bases de données relationnelles (et à notre époque d'applications NoSQL, c'est plutôt probable).

Deuxièmement, lorsqu'il existe un DBA ou un rédacteur de requête à temps plein (quel que soit le titre), la compréhension est également de moindre importance.

Ce n'est vraiment important que si le développeur doit être touche-à-tout et si ses projets exigent l'utilisation d'une base de données relationnelle (par exemple, dans des applications Web démodées ou en se connectant à des bases de données existantes).

Mon opinion personnelle: Non. Un développeur de logiciel expérimenté devrait pouvoir acquérir une nouvelle compétence (telle que SQL) s'il le souhaite et quand il le souhaite, et non «par défaut». La flexibilité et la capacité d'apprendre et de comprendre sont, à mon humble avis, ce qui différencie un bon développeur d'un bon développeur. La règle du «marteau en or» s'applique également - si vous avez un développeur disposant de connaissances approfondies en SQL, il est très probable que ce développeur va extraire l'outil qu'il connaît le mieux - les bases de données relationnelles - pour tenter de résoudre tous les problèmes sans avoir nécessairement être la meilleure solution. Bien sûr, cela vaut également pour les avocats de NoSQL,;).

Choisir un bon outil pour le bon travail est ce qu’un programmeur expérimenté devrait savoir.

— Cthulhu
source

Les bases de données NoSQL ne traitent pas plus de données, ni plus rapidement que les bases de données relationnelles. Je ne sais pas où vous avez entendu cela, mais c'est manifestement, dangereusement faux.

— Aaronaught

@Aaronaught - Edité, merci pour le heads-up de mon hypothèse prématurée, :).

— Cthulhu

7

Découvrez cette introduction à la programmation informatique sur Wikipédia:

La programmation informatique (souvent abrégée en programmation ou codage) est le processus de conception, d’écriture, de test, de débogage / dépannage et de gestion du code source des programmes informatiques. Ce code source est écrit dans un langage de programmation. Le but de la programmation est de créer un programme qui présente un certain comportement souhaité.

Les requêtes de base de données ont leurs propres langues, elles pourraient être conçues, testées, déboguées et conservées. Le but d'une requête de base de données est de vous permettre d'obtenir les informations dont vous avez besoin, de la manière dont vous en avez besoin.

Donc, je pense que c'est de la programmation, définitivement.

— Guiman
source

7

Un bon ingénieur logiciel spécialisé dans les applications d'entreprise et de gestion (EDIT: spécifiquement dans les projets utilisant un SGBDR) devrait avoir une connaissance approfondie de la rédaction de requêtes de base de données relationnelles au format standard. En outre, ils devraient être capables de comprendre un schéma complexe et de proposer des conceptions de schéma d'une complexité au moins modérée.

Une conception de schéma extrêmement avancée ou compliquée devrait être le domaine d'un modélisateur de données ou d'un architecte fonctionnel.

Cela ne signifie pas non plus que les programmeurs de bases de données n'ont pas de place. Les procédures stockées complexes, les requêtes complexes et efficaces ainsi que la conception et l'architecture logicielles de couche base de données centrées sur les outils et offres uniques d'un fournisseur de base de données unique (par exemple, Oracle, MySQL, SQLServer, etc.) devraient être laissées autant que possible aux logiciels professionnels. des ingénieurs expérimentés dans ces processus hautement spécialisés et compliqués.

La grande majorité des systèmes d'entreprise et d'entreprise ne justifient toutefois pas, à mon avis, le besoin de modélisateurs de données et de programmeurs de bases de données spécialisés, mais j'ai déjà travaillé sur de tels projets avant de pouvoir bénéficier du savoir et de l'expertise apportés par ces personnes.

— arbre_érable
source

2

-1: pas du tout d'accord pour dire qu'un "bon" ingénieur en logiciel devrait être un expert des requêtes de bases de données relationnelles.

— John Saunders

3

Seriez-vous toujours en désaccord si je disais qu’un bon ingénieur en logiciel d’applications pour entreprises ou entreprises (par opposition aux systèmes embarqués, etc.) et si je disais que cette personne devrait être un expert des requêtes de base de données relationnelles STANDARD (sans le vendeur de pantalons de fantaisie)? comme des requêtes analytiques, etc.)? Une compréhension approfondie des instructions SQL SELECT, de tous les types de jointures, de unions, de croisements et de fusions, de vues en ligne, de conditions, de classement et de regroupement des ensembles de résultats doit être parfaitement comprise et amplement démontrée par TOUT ingénieur en logiciel portant les étiquettes que j'ai indiquées ci-dessus.

— maple_shaft

4

Meh Je travaille dans une grande entreprise de logiciels et nous ne traitons aucun système de gestion de base de données relationnelle. Mon dernier travail de développement de logiciels de bureau ne nécessitait aucun SQL non plus. Je ne sais pas comment vous définissez les applications d'entreprise et d'entreprise, mais il me semble que votre vision des choses est un peu étroite.

— Adam Lear

2

Je maintiens ce que j'ai dit. Théoriquement, si l’application est bien hiérarchisée et bien composée, il n’est pas nécessaire, mais dans toute mon expérience professionnelle, mon équipe et moi-même aurions été désavoués si nous n’étions pas des experts de SQL, même lorsque nous avions une équipe dédiée à la conception et au développement de SGBDR. Peut-être suis-je vieux jeu ou ai-je juste une chance terrible dans ma carrière?

— maple_shaft

3

@maple_shaft Oui, ce n'est pas que les applications sur lesquelles j'ai travaillé étaient suffisamment composant. C'est qu'ils n'ont pas utilisé de SGBDR, un point c'est tout. Différents domaines, je suppose. Le fait est que vous ne pouvez pas dire que chaque développeur d'entreprise / entreprise doit être bon en SQL. Ce n'est tout simplement pas vrai. Soyez bon si vous l'utilisez. Ne vous inquiétez pas trop si vous n'en avez pas besoin avant d'en avoir besoin, comme avec tout autre langage ou technologie.

— Adam Lear

6

D'autres ont déjà répondu à votre question sur les requêtes de base de données.

La conception de base de données est un type particulier de conception. Ce n'est pas si difficile à apprendre, mais le concepteur de base de données typique n'a pas beaucoup d'occasions de concevoir une base de données.

L'emplacement dans lequel je travaille a maintenant la même conception de base de données qu'en 1970. Nous avons déplacé la base de données d'IDMS vers DB2, mais c'est la même conception de base de données réseau. J'ai eu l'occasion de créer 5 nouvelles tables DB2 au cours des 9 années où j'ai travaillé ici.

Je soupçonne qu’il existe très peu de lieux de travail avec un concepteur de base de données dédié. Donc, je conclurais que la conception de base de données est considérée comme faisant partie du répertoire d'un analyste senior.

— Gilbert Le Blanc
source

5

Je suis franchement étonné que nombre d'entre nous pensent que chaque développement tourne autour d'une base de données, et d'une base de données SQL.

D'autres ont évoqué les nombreuses manières dont nous pouvons éviter l'utilisation du langage SQL dans nos travaux, même lorsque nous travaillons (indirectement) avec des bases de données, mais qu'en est-il de tous les développeurs qui écrivent le micrologiciel des 101 produits électriques que chacun de nous posséder? Qu'en est-il des gars spécialisés dans la surveillance en temps réel?

Je suggérerais que la majorité des développeurs actuels auront des compétences en SQL à des degrés divers, mais c'est loin d'être un baromètre de leurs capacités.

— cjmUK
source

5

Je pense que vous surestimez l’importance des bases de données dans les logiciels.

De nombreuses classes d'applications ne sont pas centrées sur les bases de données.

Avons-nous besoin d'un SGBD dans les traitements de texte et les éditeurs d'image maintenant? Qu'en est-il des systèmes de reconnaissance vocale et de vision par ordinateur, ces systèmes contiennent-ils beaucoup de requêtes de base de données?

Et que dire des éditeurs vidéo linéaires et des moteurs physiques de jeux vidéo?

— Alex Jasmin
source

5

Je m'attendrais à ce qu'un développeur généraliste connaisse au moins les technologies de base de données (relationnelles ou non) et puisse discuter des avantages et des inconvénients de leur utilisation. Sinon, je crains qu'ils ne sachent tout simplement comment insérer des données dans des fichiers plats.

— Barry Brown
source

4

Je ne pense pas que l'écriture de requête devrait être une exigence fondamentale pour les programmeurs. Cela dit, j’estime qu’un programmeur capable d’écrire des requêtes et de concevoir des bases de données aurait plus de valeur pour une organisation.

Cependant, si ce programmeur peut uniquement écrire des requêtes de type "select * from tblxxxx", je ne considérerais pas ce programmeur comme un expert. De même, si la base de données conçue par ce programmeur place des relations un-à-plusieurs dans une table au lieu de deux, alors je ne considérerais pas ce programmeur comme un expert.

Voici comment j'explique cela aux non-informaticiens. Les professionnels de l'informatique se spécialisent dans des domaines similaires à ceux des menuisiers, électriciens et plombiers dans leurs domaines respectés. Ils ont tendance à faire double emploi avec certaines compétences mais ne sont pas des experts dans tous les domaines. Un électricien peut effectuer des tâches simples de menuiserie en toute confiance, mais il ne serait pas de bon augure d'essayer de s'attaquer à des structures complexes.

De même, un programmeur peut et doit savoir écrire ou manipuler des requêtes simples et des conceptions de base de données, mais ne doit pas concevoir de structure de données complexe.

— Michael Riley - AKA Gunny
source

3

En regardant autour de nous, cela dépend:

Nos développeurs de bureau / Web / serveur . Au moins obligé d'écrire des déclarations crud de base à avancées en fonction de leur spécialité. Pour l'optimisation, nous avons quelques administrateurs spécialisés dans la base de données.
Nos programmeurs intégrés . Un bon nombre d'entre eux n'ont jamais passé "select * from mytable". Cependant, cela a également changé ces derniers mois avec l’introduction de sqllite dans leurs projets.

— Carra
source