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

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.

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:

1. Ils sont généralement inexpérimentés.
2. 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 .

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.