Discussion :

[antrax2013]

Le A, c'est Adminstrator non?
Donc le rôle du DBA, c'est la maintenance, les back up, être capable d'expliquer le crash d'une DB etc

Pour moi, il est évident que c'est le rôle du développeur de gérer les injections SQL, de placer les index au bon endroit, de savoir lire un query process plan etc

Et conseiller les développeurs sur les requêtes pour éviter les plantages

[Lyche]

moi, il est évident que c'est le rôle du développeur de gérer les injections SQL, de placer les index au bon endroit, de savoir lire un query process plan etc

Un dev web doit savoir faire ça? ou il faut être spécialisé SQL? Parce que franchement, je travail avec des dev web tous les jours, et si on repassait pas derrière eux avant la mise en prod, bonjour les pertes de perf et les procédures illisibles qui sont pondues...

à chacun sa spécialité, travaillons en étroite collaboration et les applications s'en porteront mieux.

[Nathanael Marchand]

Bien que je sois d'accord, partiellement, avec toi. On voit bien que c'est loin d'être le cas.

Pour éviter le problème il faut y être sensibilisé et être dans une "structure" qui s'en préoccupe.

Et quelque part ça tu ne peux pas l’exiger d'un candidat junior. De plus tu ne peux te battre seul.

En plus à mon sens ça ne doit pas être rédhibitoire à l'embauche d'une personne. Les bonnes pratiques ça acquièrent bien souvent au contact des plus chevronnés ou en subissant les effets d'une mauvaise pratique. C'est aussi le rôle de l'entreprise de "former".

Après si tu es expert c'est autre chose. Mais bon on dérive du sujet.

Pour moi, je ne considère pas ca comme une bonne pratique, mais comme une base de l'accès aux données. Pour peu qu'on prenne un cours et/ou tutoriel un peu bien concu c'est expliqué!

[lutecefalco]

Un dev web doit savoir faire ça? ou il faut être spécialisé SQL? Parce que franchement, je travail avec des dev web tous les jours, et si on repassait pas derrière eux avant la mise en prod, bonjour les pertes de perf et les procédures illisibles qui sont pondues...

à chacun sa spécialité, travaillons en étroite collaboration et les applications s'en porteront mieux.

On est une équipe de dev web, et oui on doit savoir faire ça.
La partie SQL est une partie non négligeable de l'entretien

[Lyche]

On est une équipe de dev web, et oui on doit savoir faire ça.
La partie SQL est une partie non négligeable de l'entretien

Mais entre savoir faire une requête SQL et savoir maintenir pleinement une BDD qui doit monter en charge, faire un UML/MCD puis définir les différentes procédures de gestion des données, les batch de reconstructions d'index, savoir où poser les index, connaitre les subtilité du sgbd avec lequel on travail.. Tu peux pas faire les deux, connaitre parfaitement ton framework ET le langage de ton sgbd.

Non je dis pas que les dev web ne savent pas faire et ne devrait pas faire.
Je dis juste que chacun son métier, sa spécialité et que pour sortir du contexte du SELECT simple, il faut un certain bagage en dev de BDD. Et qu'avoir des équipes dédiées au BDD et au SQL c'est important et même essentiel.

[lutecefalco]

MCD, création des requêtes/proc stock, définition d'index, définir si on veut des locks par page ou row, tout ce genre de trucs, c'est à nous de le faire

[Bluedeep]

Mais entre savoir faire une requête SQL et savoir maintenir pleinement une BDD qui doit monter en charge, faire un UML/MCD puis définir les différentes procédures de gestion des données, les batch de reconstructions d'index, savoir où poser les index, connaitre les subtilité du sgbd avec lequel on travail.. Tu peux pas faire les deux, connaitre parfaitement ton framework ET le langage de ton sgbd.

Personnen n'a jamais dit que :
- maintenir pleinement une BDD
- définir les batch de reconstructions d'index
faisait parti du boulot du développeur.

En revanche, tout le travail de programmation dans la base (disons tous ce qui relève du DML + la définition des vues) c'est clairement du boulot de dev.

Poser les index est peut être à la limite entre les deux (puisque cela peut réclamer une connaissance spécifique du SGBD en terme d'optim).

Non je dis pas que les dev web ne savent pas faire et ne devrait pas faire.
Je dis juste que chacun son métier, sa spécialité et que pour sortir du contexte du SELECT simple, il faut un certain bagage en dev de BDD. Et qu'avoir des équipes dédiées au BDD et au SQL c'est important et même essentiel.

Sauf que ton équipe dédiée, qui te sera précieuse pour l'optim, ne te sera d'aucun secours pour le développement des proc métiers de la base qui réclame par définition la connaissance de l'application.

[Lyche]

Personnen n'a jamais dit que :
- maintenir pleinement une BDD
- définir les batch de reconstructions d'index
faisait parti du boulot du développeur.

En revanche, tout le travail de programmation dans la base (disons tous ce qui relève du DML + la définition des vues) c'est clairement du boulot de dev.

Poser les index est peut être à la limite entre les deux (puisque cela peut réclamer une connaissance spécifique du SGBD en terme d'optim).

Je vois pas en quoi c'est plus du boulot du dev web dont c'est pas la spécialité et dont les connaissances en BDD peuvent être limité par le manque de pratique quotidien. Je vois clairement le différence entre quelqu'un qui fait de la BDD 8h par jour et quelqu'un qui s'en sert d'appoint.

Sauf que ton équipe dédiée, qui te sera précieuse pour l'optim, ne te sera d'aucun secours pour le développement des proc métiers de la base qui réclame par définition la connaissance de l'application.

En quoi être Dev SQL m'empêche d'avoir la connaissance métier? le SQL c'est de la restitution de données et de l'insertion sous conditions. Je dirais même que l'avantage de la spécialisation c'est que chacun peut réaliser sa partie plus rapidement pour la mettre à disposition des autres. Mais je pense que c'est une vision différente de la votre. Je suis pour la spécialisation et la maitrise totale de son environnement de travail, s'étendre sur plusieurs langages et surtout plusieurs technologies je trouve que c'est de la perte de temps. (Avis très personnel)

[lutecefalco]

DBA et dév SQL, tu trouves pas ça n'importe où, faut déjà une grosse structure.
Donc les développeurs, web ou autres, se doivent d'avoir un bagage SQL qui va un peu plus loin qu'un pauvre SELECT * ou INSERT

[Bluedeep]

En quoi être Dev SQL m'empêche d'avoir la connaissance métier? le SQL c'est de la restitution de données et de l'insertion sous conditions.

Non, c'est aussi le codage des principales règle métiers de l'application.

Je dirais même que l'avantage de la spécialisation c'est que chacun peut réaliser sa partie plus rapidement pour la mettre à disposition des autres.

Certes, l'idéal est d'avoir un infographiste, un intégrateur HTML CSS, des développeurs C#, un spécialiste pour la base de donnée, un spécialiste Biztalk pour pour les ordonnancements, etc ....

Bon, après cela dépend de la taille du projet.

Le problème est que le nombre de techno mise en oeuvre n'est pas toujours proportionné à la taille du projet.

Mais je pense que c'est une vision différente de la votre. Je suis pour la spécialisation et la maitrise totale de son environnement de travail, s'étendre sur plusieurs langages et surtout plusieurs technologies je trouve que c'est de la perte de temps. (Avis très personnel)

Je suis d'accord avec toi sur le principe, mais sans doute pas avec le découpage que tu imagines.

[Lyche]

Non, c'est aussi le codage des principales règle métiers de l'application.

C'est bien ce que je dis, tu penses qu'un dev SQL n'est pas capable de comprendre les règles métier. Mais une bonne partie des RG se passent en BDD et je pense que sur certains processus un dev web ne sera pas capable de dev une procédure sql complexe optimisée et performante.

Certes, l'idéal est d'avoir un infographiste, un intégrateur HTML CSS, des développeurs C#, un spécialiste pour la base de donnée, un spécialiste Biztalk pour pour les ordonnancements, etc ....

Bon, après cela dépend de la taille du projet.

Le problème est que le nombre de techno mise en oeuvre n'est pas toujours proportionné à la taille du projet.

Je suis d'accord avec toi sur le principe, mais sans doute pas avec le découpage que tu imagines.

Pour moi le web est un métier, le design un autre, le SQL et la gestion des données en sont un autre.
Je suis navré, mais la logique de travail en BDD n'est pas du tout la même qu'en dev web ou applicatif (déjà qu'entre web et app c'est pas pareil du tout). Et faire la gymnastique mentale 35fois par jour pour se plonger d'un côté ou de l'autre du dev, c'est tout bonnement une perte de temps, d'énergie et de plus grandes chances de problèmes dans le développement.

[lutecefalco]

Pour moi le web est un métier, le design un autre, le SQL et la gestion des données en sont un autre.
Je suis navré, mais la logique de travail en BDD n'est pas du tout la même qu'en dev web ou applicatif (déjà qu'entre web et app c'est pas pareil du tout). Et faire la gymnastique mentale 35fois par jour pour se plonger d'un côté ou de l'autre du dev, c'est tout bonnement une perte de temps, d'énergie et de plus grandes chances de problèmes dans le développement.

C'est vrai pour les très gros projets ça.
Quand t'as un projet avec 2 ou 3 dévs (et en 8 ans de taff, j'ai vu que ça) bah t'as pas les moyens de te payer un dév SQL

[Lyche]

C'est vrai pour les très gros projets ça.
Quand t'as un projet avec 2 ou 3 dévs (et en 8 ans de taff, j'ai vu que ça) bah t'as pas les moyens de te payer un dév SQL

Mais libre à vous de croire que le sérieux et les bonnes pratiques doivent se cantonner aux "gros projets" mais on est pro ou on l'est pas. Et pour moi c'est du charlatanisme que de vendre un produit développé par quelqu'un qui n'est pas spécialiste.

C'est comme si je demandais à mon boulanger de me faire un super gâteau pour mon anniversaire.. Il sera bon, mais manquera la touche finale que le vrai pâtissier lui aurait rajouté de par sa connaissance du métier et des choses à faire.
Les bases de données sont trop peu considéré de nos jours et c'est un vrai problème car elles sont plus importantes qu'on ne le pense et que les perfs et la sécurité des données d'une appli sont non seulement liées à la qualité du dev, mais aussi à la qualité d'une BDD.

[lutecefalco]

Mais libre à vous de croire que le sérieux et les bonnes pratiques doivent se cantonner aux "gros projets" mais on est pro ou on l'est pas. Et pour moi c'est du charlatanisme que de vendre un produit développé par quelqu'un qui n'est pas spécialiste.

C'est comme si je demandais à mon boulanger de me faire un super gâteau pour mon anniversaire.. Il sera bon, mais manquera la touche finale que le vrai pâtissier lui aurait rajouté de par sa connaissance du métier et des choses à faire.
Les bases de données sont trop peu considéré de nos jours et c'est un vrai problème car elles sont plus importantes qu'on ne le pense et que les perfs et la sécurité des données d'une appli sont non seulement liées à la qualité du dev, mais aussi à la qualité d'une BDD.

Question de sous c'est tout.
Et à t'écouter, tous les dévs non web sont des grosses tanches en SQL, bah c'est pas le cas

Entre une bonne tarte tatin à 10€ faite par mon boulanger et une un peu meilleure à 20€ faite par mon boulanger avec l'aide d'un patissier, bah je prends celle à 10€

[Lyche]

Question de sous c'est tout.
Et à t'écouter, tous les dévs non web sont des grosses tanches en SQL, bah c'est pas le cas

Entre une bonne tarte tatin à 10€ faite par mon boulanger et une un peu meilleure à 20€ faite par mon boulanger avec l'aide d'un patissier, bah je prends celle à 10€

bah je préfère payer plus cher et me régaler.

Pour le reste, je dis juste "chacun son métier". Et je n'ai pas dis que les dev web sont des tanches, je dis qu'ils manquent de connaissance sur les subtilités du deb BDD tout comme je peux faire un site web mais qu'il y aura des erreurs de perfs et de dev parce que j'ai pas la maitrise de framework ou du langage de dev.

Libre à vous de vendre des sous produits qui vont lâcher dans 3 ans et qui seront rendus en retard parce que des personnes n'étaient pas à leur place dans la gestion du projet. Personnellement je préfère rendre à l'heure un projet dont les étapes respectives du dev seront gérées par des spécialistes de leurs métier.

De plus, un dev SQL c'est pas bien plus cher qu'un dev .net ou java (voir même moins cher). Donc ne me parlez pas d'argent comme excuse de pas prendre les bonnes personnes à leur place.

[lutecefalco]

bah je préfère payer plus cher et me régaler.

Bah c'est pas la philosophie de ceux qui payent dans la majorité des cas ...

De plus, un dev SQL c'est pas bien plus cher qu'un dev .net ou java (voir même moins cher). Donc ne me parlez pas d'argent comme excuse de pas prendre les bonnes personnes à leur place.

Et quand la partie DB représente 10 à 15% de ton projet, tu laisses le dév SQL à la machine à café le reste du temps?

[Lyche]

Bah c'est pas la philosophie de ceux qui payent dans la majorité des cas ...

Bah qu'ils se plaignent pas d'avoir des projets bancales.

Et quand la partie DB représente 10 à 15% de ton projet, tu laisses le dév SQL à la machine à café le reste du temps?

Etrangement, si tu n'as qu'un projet dans ta boite, je vois pas comment tu peux vivre. Si ton projet n'est qu'à 15% en BDD, bah le reste du temps tu le mets sur d'autres projets qui nécessitent 15% de de temps de dev BDD.. Il faut pas 35dev BDD non plus >_< j'espère que tu n'étais pas sérieux sur ta question parce que c'est quand même limite là.

1 dev BDD pour 3 ou 4 dev web. c'est largement suffisant, et 1 DBA pour la gestion des serveurs et l'organisation des processus.

[lutecefalco]

T’inquiètes pas pour nous.
Dans ma boite, l'IT représente 1 milliard d'euros par an.
A croire qu'on est plus fort que la moyenne en SQL.

Le SQL, c'est comme tout, plus tu y touches plus tu deviens performant.
Certes, on arrivera jamais au niveau d'un mec qui fait ça 100% de son temps, mais ça suffit pour 99.99% des projets

[Lyche]

T’inquiètes pas pour nous.
Dans ma boite, l'IT représente 1 milliard d'euros par an.
A croire qu'on est plus fort que la moyenne en SQL.

Je suis très content pour toi. Cependant je suis certains qu'un audit de vos BDD vous ferait grandement déchanter.

C'est facile de nos jours les perfs sont compensé par des machines 48coeurs et 128Go de RAM..

Bref, je préfère cesser de discuter de toute façon les grandes boites ont toujours raison puisqu'elles font de gros chiffres d'affaire.

Je préfère rester dans ma petite boite à 40Millions par an et offrir des services complets en BDD.

pardon d'avoir douté de la compétence de personnes qui se croient indispensable dans tous les domaines je me repent et ne vous embêterais plus sur un sujet qui est le mien depuis plusieurs années déjà.
Mon travail est donc inutile, je vais aller me suicider.

[lutecefalco]

J'ai pas dit qu'un dév SQL était inutile. Je pense juste que là où sa place est justifiée ne représente pas la majorité des boites.

On n'a pas besoin d'un ingénieur motoriste de F1 pour concevoir des méganes ou des 308