30 ans passé et j'apprends mon N-ième langage et vous ?

Envoyé par Michael REMY

je veux pas polémiquer mais quand-même, comment on peut ne pas connaître et pratiquer le SQL en étant ingénieur ?

En ne travaillant pas avec des bases de données? Ou juste en ayant un besoin limité: pour cela, il n'y a pas besoin de connaître ou de pratiquer le SQL, un vague fichier d'aide suffit.

Pour répondre au sujet, je ne pratique aujourd'hui qu'un langage, le C++.

Ensuite, c'est comme les langues étrangères, il faut faire la différences entre celles qu'on a appris à l'école, celles qu'on met sur son CV, et celles qu'on serait capable d'utiliser dans la vraie vie...

Pour l'informatique, j'ai déjà écrit de vrais programmes (dans un cadre professionnel) en

C++
C
Delphi
AS3/Flex
VBA Word et Excel
les vieux langages macros d'Excel (versions 2 et 3)

J'ai appris sérieusement, et je pense être capable d'utiliser
J
AWK

J'ai une compétence "scolaire" (your mileage may vary, comme ils disent sur l'internet) en
Fortran
Delphi
ASM 86
Basic

Je voudrais apprendre, quand j'aurai le temps
APL
Lisp
Algol
Forth

je n'apprendrai pas, même si j'ai le temps et que je suis atteint d'Alzheimer
Java
Cobol
SQL
Haskell

Les vraies langues que je sais parler ce sont
Anglais
Chinois

Je dois pouvoir m'en sortir en
Latin

Et je mets sur mon CV
Allemand
Russe
Grec

Et j'ai 47 ans,

Francois (ce n'est pas un langage, c'est mon prénom)

[Michael REMY]

je n'apprendrai pas, même si j'ai le temps et que je suis atteint d'Alzheimer
(...)SQL(...)

moi je veux bien, mais bon ça fait bizarre , vu qu'il n'y a pas de réel alternative universel à ce langage. C'est pas comme le java ou le C car il y a plein d'autres languages alternatifs à eux, mais là, SQL....
Surtout quand on sait jusqu'où on peut aller en SQL, on se simplifie bcp la vie dans l'attaque et formattages des données tirés d'une base (plutôt que le faire en c++/java).

Je dis bien savoir l'utiliser et le connaitre. J'entends très bien qu'on peut vivre sans y toucher, mais il faut au moins le connaître pour être un très bon programmeur dans le domaine informatique . où alors t'es un gros codeur qui ne code que des pilotes hardware ou pure matériel ou que des librairy toute la journée (humour....mais avec un pe ude vrai).
Rassurez-moi les gars, le SQL fait parti des savoir fondamentaux d'un ingé en informatique en 2012 (en france) ?
Ayant fait le parcourt alternatif à l'ingénieurie (bac,bts,licence,miage,dess), j'ai fait du sql dans chaque cursus et dans chaque projet projefionnel de ma vie (sauf tamagoshi jbuilder!).

Envoyé par Michael REMY

Je dis bien savoir l'utiliser et le connaitre. J'entends très bien qu'on peut vivre sans y toucher, mais il faut au moins le connaître pour être un très bon programmeur dans le domaine informatique . où alors t'es un gros codeur qui ne code que des pilotes hardware ou pure matériel ou que des librairy toute la journée

Pas forcément... D'abord, il y a toutes sortes de programmeurs qui ne voient jamais de bases de données. Ceux qui font de l'embarqué, tout le calcul scientifique.

Ensuite, il y a des gens qui utilisent des bases de données sans SQL : SAS par exemple, ou des choses plus confidentielles.

Enfin, il y a tout ce qui utilise des données en lecture directe, sans SGBD tout cela. Je suis prêt à pariet que c'est la majorité (en terme d'applications qui tournent, pas de programmeurs, les SGBD sous SQL, c'est notoirement consommateur en ingénieurs)


Du coup, j'aurais tendance à reformuler ta phrase... Pour travailler en SSII, en informatique de gestion, il est inconcevable de ne pas connaitre SQL. Pour le reste, YMMV...

Francois

[Bluedeep]

Envoyé par fcharton

Pas forcément... D'abord, il y a toutes sortes de programmeurs qui ne voient jamais de bases de données. Ceux qui font de l'embarqué, tout le calcul scientifique.

Dans le cas supra, où l'intervenant fait du HTML + php, j'ai un gros doute que ce soti pour du calcul scientifique ou de l'embarqué (à moins d'inclure dans l'embarqué un navigateur sur smartphone )

Ensuite, il y a des gens qui utilisent des bases de données sans SQL : SAS par exemple, ou des choses plus confidentielles.

SAS est en effet un cas particulier, utilisé soit par des non informaticiens spécialistes dans leur domaines (exemples les actuaires auquel il est primitivement destiné) soit des développeurs spécialisés dessus. J'ai bossé sur un projet où j'avais du prendre un intervenant SAS ; j'avais trouvé un freelance de près de 60 ans super pointu sur cet outil : le gars s'était spécialisé là dessus et ne faisait que cela.

Enfin, il y a tout ce qui utilise des données en lecture directe, sans SGBD tout cela.

Pas très fréquent.

Je suis prêt à pariet que c'est la majorité (en terme d'applications qui tournent, pas de programmeurs, les SGBD sous SQL, c'est notoirement consommateur en ingénieurs)

Je pense que tu oublies une chose : les développeurs de plus en plus nombreux qui ne mettent pas le nez dans le SQL et laisse l'ORM (mal) gérer cela. Je soupçone que le cas mis en exergue rentre dans cette catégorie.

[el_slapper]

Envoyé par fcharton

(.../...)

Du coup, j'aurais tendance à reformuler ta phrase... Pour travailler en SSII, en informatique de gestion, il est inconcevable de ne pas connaitre SQL. Pour le reste, YMMV...

Francois

même pas forcément. Je bosse en grands systèmes/COBOL. J'ai fait pas mal de DB2/SQL quand je faisais du transactionnel. Maintenant que je fais du batch, je ne me fais plus chier avec le SQL : un job décharge la table et la met sous fichier plat, je traite le fichier plat, et je recharge la table avec le fichier plat traité. C'est la différence entre quelques minutes d'execution et quelques heures.

Et si on me dit "parceque tes requêtes sont mal optimisées", c'est bien possible, mais le traitement de fichier plat se code facilement, se débuggue rapidement, et fonctionne très bien. On laisse le poids du SQL aux pauvres malheureux qui se farcissent le transactionnel. Charge à nous de leur laisser une base propre, par contre(sinon ils nous arrachent les yeux avec des cuillers à pamplemousse, et ils ont bien raison).