Discussion :

[Monstros Velu]

Bonjour,

Depuis quelques mois, je fais passer des entretiens techniques pour des développeurs, car notre équipe grossit. La cible, c'est notre application un peu datée : C#, Winforms, webservices asmx, SQL Serveur.

Du coup, je me suis établi une liste de questions, en essayant de couvrir tout ce qui me semble important sur les domaines techniques correspondant à notre besoin. Parfois, les gens ne savent rien, et ils ne sont pas pris.

Mais sur ceux qui sont plutôt bons, je remarque quelque chose : Globalement, sur .NET, ça réponds pas trop mal (même si j'hallucine parfois). Sur SQL Serveur, ils connaissent les vues, plus ou moins les indexes, ils savent faire des select et des updates (mais pas des merges) dans des transactions. Par contre, j'ai l'impression que personne n'a entendu parler des formes normales, y compris parmi ceux qui se disent compétent en SQL.

Et, je dois avouer que dans ma carrière (15ans), j'ai surtout vu des bases de données plutôt hasardeuse concernant leur modèle... au mieux, correlation; très possiblement, causalité…

Du coup, je me pose des questions sur ma question : Ce que je cherche n'est pas pertinent ? Les développeurs .NET ne connaissent rien à SQL ?

Bonne soirée !

[escartefigue]

Bonjour,

La connaissance des NF est cruciale pour modéliser une BDD elle l'est moins pour utiliser un langage de développement.
Ça reste tout de même un point important pour le développeur, car comprendre ce type de fondamentaux permet d'avoir un regard critique et d'être force de proposition pour faire évoluer la BDD.
Selon que l'on recrute l'un ou l'autre des profils, le niveau d'exigence n'est donc pas le même.

[vanagreg]

Bonjour,

Comme le dit escartfigue, ces notions vont être importantes surtout en cas de modélisation de la BDD. C'est très rare d'avoir des développeurs qui savent modéliser correctement, même parmi ceux dont la spécialité c'est la base de données justement.
Je pense que quand un développeur .net par exemple indique avoir des connaissances en SQL, il sous-entend les instructions DML (select, insert, update, delete, merge).
J'ai également vu beaucoup de base de données mal modélisées et malheureusement après un vécu certain il est difficile d'y faire quoi que ce soit pour y remédier, à part une refonte complète.
En tout cas si tu prévois de faire une application de A à Z, il ne faut surtout pas laisser les développeurs dont la modélisation BDD n'est pas leur spécialité le faire, car ils modéliseront comme cela les arrange (c'est du vécu, j'ai eu des ids de pk dans du json...).

[François DORIN]

Bonjour,

Je rejoins mes camarades sur la connaissance des formes normales. Si l'objectif c'est d'agir et de faire évoluer une base de données, c'est indispensable de les connaître. S'il s'agit uniquement de faire des requêtes sans agir sur la structure de la base de données, ce n'est pas indispensable tout en restant un gros plus.

Pour être un peu plus nuancé et précis, il existe plusieurs formes normales. Connaître le côté "académique" (savoir que NF1 = atomicité, etc...) est, de mon point de vue, inutile. Par contre, connaître les règles se cachant derrière les formes normales, ça oui, c'est indispensable.

[Monstros Velu]

Bonsoir !

Je connais les formes normales jusqu'à la 6ème, en incluant les formes intermédiaires. Je pensais que le bagage technique d'un développeur .NET correct était au alentours de BCNF.

Ce soir, j'ai fait passer un entretien à un dev .NET dont le commercial disait qu'il était "très fort sur SQL Serveur". Il ne connaissait pas les formes normales, mais il ne savait pas non plus ce qu'était un cross join, un merge, croyait que les index étaient les clefs primaires et étrangères, pensait que les vues étaient optimisées par défaut, et n'avait jamais entendu parler de transaction... (et en fait, il était à peine meilleur en C#...)

Bon, je vais pleurer un coup et je crois que je vais me faire une raison : Si on veut des gens qui connaissent un peu SQL, il faut les former soi-même... Du coup, on a pris un junior enthousiaste...

[fsmrel]

Bonsoir Monstros,

Je connais les formes normales jusqu'à la 6ème

Quelles définitions utilisez-vous ? (Il y en a tellement !)

Je pensais que le bagage technique d'un développeur .NET correct était au alentours de BCNF.

Un développeur n’est pas censé connaître les formes normales, c’est du ressort des spécialistes des bases de données relationnelles. Parler des formes normales sans savoir —entre autres ! utiliser les axiomes d’Armstrong est en général d’un intérêt limité. Même les pères de Merise sont ignares en la matière (à quoi leur sert le particulièrement utile axiome d’augmentation ?) Pour sa part quand IBM traite de DB2, elle se plante lamentablement au sujet de la 1NF, et ça n’est pas mieux avec la 2NF ou la 3NF, et c’est silence radio quant à la BCNF, c’est dire ! Alors que demander à un développeur !

[escartefigue]

Par ailleurs, je ne suis pas certain que l'approche soit la bonne.
A mon avis, pour un développeur, ce n'est pas grave de ne pas connaître tous les ordres SQL (comme le MERGE ou le CROSS JOIN que vous citez en exemple), car il suffit d'ouvrir la documentation de référence pour trouver la liste exhaustive des ordres, avec leur syntaxe et des exemples d'utilisation.

Par contre, ne pas connaître les fondamentaux sur la façon de construire les requêtes, ne pas savoir ce qu'est un prédicat sargable, utiliser les colonnes IDENTITY comme critère de rangement, penser qu'il existe un "ordre par défaut" dans une table et autres énormités que l'on rencontre fréquemment, ça c'est plus préoccupant : sur ces sujets, la documentation de base ne suffit pas, il faut de la formation, de l'accompagnement, et les conséquences sur les performances et la fiabilité du résultat sont autrement plus lourdes.

[al1_24]

A mon avis, pour un développeur, ce n'est pas grave de ne pas connaître tous les ordres SQL (comme le MERGE ou le CROSS JOIN que vous citez en exemple), car il suffit d'ouvrir la documentation de référence pour trouver la liste exhaustive des ordres, avec leur syntaxe et des exemples d'utilisation.

Tu en connais beaucoup des développeurs applicatifs qui ouvrent la documentation de référence du SGBD ?
Alors qu'ils ont déjà du mal à ouvrir celle du langage qu'ils sont sensés maîtriser.

[Monstros Velu]

Par ailleurs, je ne suis pas certain que l'approche soit la bonne.
A mon avis, pour un développeur, ce n'est pas grave de ne pas connaître tous les ordres SQL (comme le MERGE ou le CROSS JOIN que vous citez en exemple), car il suffit d'ouvrir la documentation de référence pour trouver la liste exhaustive des ordres, avec leur syntaxe et des exemples d'utilisation.

S'ils ne connaissent pas leur existence, ils ne l'utilisent pas : La quantité de code que je vois avec 1 update + 1 insert en fonction de si la ligne existe ou pas montre qu'ils ne savent pas que le merge existe. Je ne leur demande pas de connaître toute la syntaxe par coeur. Quand un dev standard me dit "INSERT+UPDATE", j'accepte la réponse. Quand un dev qui se dit fort en SQL me dit qu'il n'a jamais entendu parler de merge, c'est qu'il n'est pas fort en SQL...

Le niveau que je demande en SQL à un DEV .NET, c'est à peu pres la certification "database fundamentals" de Microsoft : Ca m'assure juste qu'ils n'écrivent pas de bêtises. Mais, déjà, la plupart des devs n'ont pas ce niveau. Peut-être qu'ils utilisent trop d'ORM et de Code First...

Par contre, ne pas connaître les fondamentaux sur la façon de construire les requêtes, ne pas savoir ce qu'est un prédicat sargable, utiliser les colonnes IDENTITY comme critère de rangement, penser qu'il existe un "ordre par défaut" dans une table et autres énormités que l'on rencontre fréquemment, ça c'est plus préoccupant : sur ces sujets, la documentation de base ne suffit pas, il faut de la formation, de l'accompagnement, et les conséquences sur les performances et la fiabilité du résultat sont autrement plus lourdes.

Pour ça, j'accompagne. Je fais des codes review de leur code et de mon code pour les faire évoluer, et des ateliers pour des points particuliers.

Mais là, je recherchais un profil plus avancé, dev .NET capable de modéliser correctement (parce que j'ai besoin d'un back-up qui comprend ce que je fais et capable de prendre en charge des fonctionnalités du projet), et je n'ai pas trouvé.