Discussion :

[Mat_MAT_BI]

Hohoho.. doucement... un count(*).. un peu de pipeau et ça suffit

[GreatDeveloperOnizuka]

Il faudrait aussi connaitre les connaissances connexes requises pour être embauchées sur ces SGBD.
Par exemple :
SQLServer --> PowerShell
MySQL --> bash
MongoDB --> Nodejs
Oracle --> PLsql

Il y a des gens "experts" en Oracle qui connaissent pas le PL ? La même pour le T-SQL sur SQL Server Même moi qui suit noob je connais ces 2 langages

[Mat.M]

programmer sous Oracle et ne pas connaître PL-SQL ça me parait impossible...

Hohoho.. doucement... un count(*).. un peu de pipeau et ça suffit

je comprends bien que c'est de l'houmour Mr Mat mais dans certaines directions informatiques un SELECT COUNT(*) ça risque de mal passer

Vous risquez de vous attirer les foudres de votre chef de projet en faisant cela

[Glutinus]

programmer sous Oracle et ne pas connaître PL-SQL ça me parait impossible...

C'est pour ça qu'on a créé les ETL, type Datastage, Informatica ou SSIS...

... Pour après faire du code trivial qui appelle des proc-stocks

[GreatDeveloperOnizuka]

C'est pour ça qu'on a créé les ETL, type Datastage, Informatica ou SSIS...

... Pour après faire du code trivial qui appelle des proc-stocks

[TROLL]Oui il y a les experts qui font du vrai dév et les noobs qui du no code [/TROLL]

Sinon perso coder du PL/SQL T-SQL > all . J'ai manipulé pas mal d'ETL (surtout SSIS et SAP Data Services) je suis toujours revenu à du PL/SQL ou T-SQL putain, sauf pour des trucs genre DTS Wizard sur des transferts de data. Je suis vraiment trop taré ou trop naze pour savoir utiliser des outils déjà tout prêt . Dire que les mecs du fonctionnels qui captent que dalle sont payés une blinde pour faire 3 mappings mais qui t’appellent pour coder un truc customized en SQL après .

[autran]

@ Glutinus & DuyBinh Peut on gagner sa vie en ne connaissant que PLSql ou transacSQL sans être un DBA ?

[GreatDeveloperOnizuka]

@ Glutinus & DuyBinh Peut on gagner sa vie en ne connaissant que PLSql ou transacSQL sans être un DBA ?

Bien sûr que oui, il y a plein de vieux planqués dans les boites ou sur Paris dans le domaine bancaire, ça recrute souvent des prestas pour maintenir du passif fait en PL ou T-SQL . Après c'est comme pour les autres niches Cobol, ABAP ou VBA par ex, c'est pas forcément très fun dans le marché actuel qui sont en mode IA, IoT, NodeJS, etc.

[Glutinus]

@ Glutinus & DuyBinh Peut on gagner sa vie en ne connaissant que PLSql ou transacSQL sans être un DBA ?

Pour te donner mon expérience, je fais de l'ETL et ce n'est qu'une réécriture graphique, sous forme de schéma, boite etc. de ce qu'on peut faire en SQL.
L'idée, c'est de pouvoir reproduire le SQL de manière simple, sauf qu'au bout d'un moment, bah pour tester ton entrée et ta sortie, il faut bien apprendre à l'utiliser.

Le seul truc qui est bon, c'est le déterminisme ie tu sais que le traitement mettra tant de temps pour gérer les règles de calcul, alors qu'en SQL un moindre faux-pas et tu passes à 5h de traitement ; et les logs, quand l'ETL est bien fait. Mais c'est souvent lourdingue et tu as tôt fait d'apprendre à maîriser en SQL et éventuellement en PL/SQL (surtout pour gérer les itérations).

Pour moi tu devrais pouvoir trouver des postes en PL/SQL dans beaucoup de boite, sauf que la plupart des chefs de projet ignorent souvent que leur propre projet a été développé à 90% en proc-stock, ou alors ne veulent pas l'avouer. Parce que ça fait beaucoup mieux sur un appel d'offres de mettre des jolies technos à la mode (et les développeurs expérimentés, comme moi, facture beaucoup mieux avec ces technos alors qu'un PL/SQL bien documenté dans le script et la spec fait laaaaaargement l'affaire).

Littéralement, dans une ancienne mission, j'ai eu tout un exposé de super technos. Ce qui aurait dû me mettre la puce à l'oreille, c'est que je ne maîtrisais pas toutes. Au final, on utilisait une base de données que je connaissais peu à l'époque et j'ai mis, allez pour être tranquille, un bon mois avant de taper des requêtes sans faire d'erreur. Au final, on utilisait que du SQL ; j'ai dis à mon cdp qu'il valait mieux qu'il mette en avant une expertise ou une très bonne connaissance sur la BDD plutôt que sur l'ETL, qui faisait ce que je disais plus haut : de l'encapsulation.

Mais bon, il en avait rien à branler. En même temps, la mission était tellement pourrie qu'il fallait l'embellir. Comme dit le joueur du grenier "ce n'est pas en mettant de la chantilly sur du caca que ça en fera un bon gâteau au chocolat".

[GreatDeveloperOnizuka]

Pour te donner mon expérience, je fais de l'ETL et ce n'est qu'une réécriture graphique, sous forme de schéma, boite etc. de ce qu'on peut faire en SQL.
L'idée, c'est de pouvoir reproduire le SQL de manière simple, sauf qu'au bout d'un moment, bah pour tester ton entrée et ta sortie, il faut bien apprendre à l'utiliser.

Le seul truc qui est bon, c'est le déterminisme ie tu sais que le traitement mettra tant de temps pour gérer les règles de calcul, alors qu'en SQL un moindre faux-pas et tu passes à 5h de traitement ; et les logs, quand l'ETL est bien fait. Mais c'est souvent lourdingue et tu as tôt fait d'apprendre à maîriser en SQL et éventuellement en PL/SQL (surtout pour gérer les itérations).

Pour moi tu devrais pouvoir trouver des postes en PL/SQL dans beaucoup de boite, sauf que la plupart des chefs de projet ignorent souvent que leur propre projet a été développé à 90% en proc-stock, ou alors ne veulent pas l'avouer. Parce que ça fait beaucoup mieux sur un appel d'offres de mettre des jolies technos à la mode (et les développeurs expérimentés, comme moi, facture beaucoup mieux avec ces technos alors qu'un PL/SQL bien documenté dans le script et la spec fait laaaaaargement l'affaire).

Littéralement, dans une ancienne mission, j'ai eu tout un exposé de super technos. Ce qui aurait dû me mettre la puce à l'oreille, c'est que je ne maîtrisais pas toutes. Au final, on utilisait une base de données que je connaissais peu à l'époque et j'ai mis, allez pour être tranquille, un bon mois avant de taper des requêtes sans faire d'erreur. Au final, on utilisait que du SQL ; j'ai dis à mon cdp qu'il valait mieux qu'il mette en avant une expertise ou une très bonne connaissance sur la BDD plutôt que sur l'ETL, qui faisait ce que je disais plus haut : de l'encapsulation.

Mais bon, il en avait rien à branler. En même temps, la mission était tellement pourrie qu'il fallait l'embellir. Comme dit le joueur du grenier "ce n'est pas en mettant de la chantilly sur du caca que ça en fera un bon gâteau au chocolat".

HS. T'arrives à trouver des missions à distance pour débug des PS ou truc du genre ? T'es en Ile de France ?

Sinon ça rejoint ce que je dis, la plupart des chefs en ont rien à foutre de la techno ils veulent juste que ça marche et leurs managers sont contents comme ça . De temps en temps, faut caser un nouveau projet un peu hype pour consommer son budget évidemment pour faire voir qu'on est utile .

[Glutinus]

Hohoho.. doucement... un count(*).. un peu de pipeau et ça suffit

Petite anecdote.



Je bossais chez un éditeur. La commerciale du client A me demande de faire un count(*) sur deux tables spécifiques pour un client B.
Je lui demande innocemment pourquoi. Elle m'explique que la boite voulait revendre l'évolution, mais au prix fort (devis avec développement JH ; le plus drôle c'est qu'il était persuadé qu'il suffisait que je copie-colle le fichier de code pour que ça fonctionne de l'autre côté, sans compter un minimum de paramétrage et d'adaptation, d'ordonnancement etc.). Le but étant de rassurer le client que le nombre de lignes n'était pas élevé et n'exploserait pas le batch de nuit.

Je lui fais donc une estimation : 10000 lignes pour la table A environ, 100000 lignes pour la table B, et qu'AMHA le temps de traitement ne serait pas élevé (en plus, c'était juste un simple TRUNCATE INSERT...)

Elle me revient en me disant : c'est bizarre, c'est rond... je lui indique juste que c'est une estimation, elle me redemande le nombre de lignes exact etc.

Bon au final, je lui donne... et voilà-t-y pas qu'elle envoie le nombre de lignes tels quels... ceux à quoi le client A lui dit "c'est bizarre, vous avez l'air d'avoir connaissance d'un nombre très précis de ligne.... vous n'auriez pas déjà fait le développement pour un autre client et vous essayer de nous faire facturer au max ?".

Bon après c'est leur tambouille interne, ça leur regarde, le client peut très bien refuser... mais si elle avait mis l'arrondi elle n'aurait pas eu de problème !

[Mat.M]

@ Glutinus & DuyBinh Peut on gagner sa vie en ne connaissant que PLSql ou transacSQL sans être un DBA ?

oui si le client le demande.
DuyBinh a fait une très bonne réponse à ce sujet.

[autran]

HS. T'arrives à trouver des missions à distance pour débug des PS ou truc du genre ? T'es en Ile de France ?

Non je suis sur Marseille j'ai l'impression que seuls les dev Java angular et Node sont recherchés. Mais je n'ai pas de visibilité sur les niches… je suis dans une grosse SSII et je manque de courage pour me lancer en freelance.

[Glutinus]

J'ai un collègue qui était à Nantes, qui pourtant était à Paris ce qu'était San Francisco à New York, en somme "c'est pareil mais c'est mieux, j'ai double surface, le temps est meilleur et y a le même dynamisme culture / sorties" ; en tant que freelance il avait galéré, il est revenu sur Paris... les clients sont trustés par 3 SSII, du moins dans notre domaine, et ils laissent rentrer personne d'autres.

[GreatDeveloperOnizuka]

J'ai un collègue qui était à Nantes, qui pourtant était à Paris ce qu'était San Francisco à New York, en somme "c'est pareil mais c'est mieux, j'ai double surface, le temps est meilleur et y a le même dynamisme culture / sorties" ; en tant que freelance il avait galéré, il est revenu sur Paris... les clients sont trustés par 3 SSII, du moins dans notre domaine, et ils laissent rentrer personne d'autres.

En gros Paris = go Freelance (pré Corona évidemment ) et province CDI client final mode El_Slapper