Discussion :

[Glutinus]

Et après pour la modélisation des bases, j'ai vu des merdes pondus par des pseudos experts de 20 ans d'XP donc ça veut rien dire pour moi .

Exemple parfait : j'ai sous les yeux une table de datawarehouse qui est le produit d'une table de lien N-M et deux autres.
On vient de m'envoyer la doc après que je leur ai répété que, puisqu'ils ont choisi de faire un modèle Inmon (DWH + datamart séparé) et qu'on repasse tout le temps sur cette table, pourquoi ne pas les garder séparée et faire le calcul à la cool pour le datamart...

Nouvelle spec : on rajoute une troisième table... je sens que je vais devoir maintenir très longtemps cette alim...

[GreatDeveloperOnizuka]

Exemple parfait : j'ai sous les yeux une table de datawarehouse qui est le produit d'une table de lien N-M et deux autres.
On vient de m'envoyer la doc après que je leur ai répété que, puisqu'ils ont choisi de faire un modèle Inmon (DWH + datamart séparé) et qu'on repasse tout le temps sur cette table, pourquoi ne pas les garder séparée et faire le calcul à la cool pour le datamart...

Nouvelle spec : on rajoute une troisième table... je sens que je vais devoir maintenir très longtemps cette alim...

Moi j'ai vu un truc chelou une fois, le mec avait fait des sortes de meta contraintes dans une BDD. T'es OBLIGE de respecter son truc de merde pour pouvoir faire une opération dedans (création colonne, connexion ou quoique ce soit). Du coup, tout le SI était dépendante de sa merde et donc il était directeur du développement et irremplaçable .

Bref, il a bien géré son coup en fait .

[commandantFred]

C'est un peu réducteur de parler de moteurs SQL et rien qu'à vous lire, on peut deviner le type de données que vous traitez et l'organigramme de vos équipes.
Reste que le big data est, par nature, mal schématisé et que les données voyagent de plus en plus sous forme de JSON ou de XML, avec pour chaque champ, un flag "mandatory Y/N", des champs de même nom dans la même ligne, etc... Bref, des choses qui ne rentrent pas dans une logique de table.

Je suppose que tous les DB men que nous sommes savent comment l'intégrer dans une jointure 1 à N nom,valeur... il n’empêche, les données, ce n'est pas que des moteurs, c'est aussi de l'intelligence stockée dans des architectures plus ou moins éparpillées.

J'ai un petit programme qui pond des bases sqlite de 50 millions de lignes régulièrement, puis qui les ajoute dans un dossier où un autre programme les charge par paire pour les jointurer entre elles....

Sqlite est génial pour ça. Mieux qu'un serveur, pourquoi ? Parce que la logique est synchrone et qu'il n'y a qu'un utilisateur à la fois. Dans le cas contraire, il faudrait se résoudre à empiler des centaines de milliards de lignes dans un serveur et, même s'il y en a de meilleurs que d'autres, les indexes deviendraient énormes et le système mettrait des semaines, là où sqlite ne met que quelques secondes...

Comme quoi, même si c'est difficile à expliquer à un DRH quand on cherche un job, le moteur demandé n'est pas forcément celui dont il a besoin.

Bon, maintenant, je fais du traitement de signal, de l'IA et de l'astronomie à grande échelle. Quand j'ai quelque chose à stocker, c'est rarement plus petit que 100 millions... et c'est plutôt de l'objet (Maitre - Détail ou le maître ne sert que de serveur de clé autoincrement)

Au final, je rends des graphiques qui doivent pouvoir tenir dans la ram d'une page web, bitmaps en fausses couleurs, svg de plusieurs mega bytes...., donc, je ne suis plus trop dans la pure gestion , même si j'en fais encore ... (on n'arrête jamais complètement la gestion n'est-ce pas?)

[Pierre Louis Chevalier]

Quand à tuer la concurrence, c'est la spécialité de M$, d'essayer par tous les moyens de phagocyter les produits concurrents quitte parfois à ouvrir le porte-monnaie pour racheter le produit et le laisser dépérir ensuite

Enfin dans ce cas précis c'est pas ce qui s'est passé. Avant il y avait dBase 3, puis dBase IV , la version IV n'ayant pas convaincu tous le monde, et la Paradox est venu avec une très grosse hype, la c'est pas Microsoft qui a racheté Borland ou Ashton-Tate mais c'est Borland qui a racheté Ashton-Tate en 1991, donc avec dBase. dBase à continué à être utilisé par certain développeurs mais de plus en plus avec d'autre outils logiciels, comme par exemple Clipper. Pendant ce temps la hype sur Paradox a monté et dBase IV a décliné, mais Borland était au sommet de sa gloire à un moment donné avec à la fois Paradox, Paradox Windows, dBase, Delphi et C++Builder.

Et c'est la que Microsoft a sorti Access, et en fait Access était très bien foutu, un produit bien mieux adapté que Paradox Windows pour viser les utilisateurs finaux, alors que pendant ce temps Paradox Windows était une vrai usine à gaz et ciblait en fait les développeurs. Les développeurs Borland hardcore ne sont pas restés sur Paradox Windows mais sont passés à Delphi (C++Builder pour certains) qui est un bien meilleur outil que Paradox Windows pour les développeurs, et Access a connu un succès énorme et immédiat, car il venait parfaitement compléter Word et Excel pour créer Office, avec le succès qu'on connais à ce jour.

Donc la cette victoire a été obtenue par Microsoft à la "loyale", Borland n'a pas sortie le produit qu'il fallait, Microsoft oui. Celui qui a racheté un concurrent qui a fini par disparaitre (Ashton-Tate / dBase ) ici c'est Borland, pas Microsoft.

Après quoi Philippe Kahn, le PDG de Borland a pris une série de décisions désastreuses, et il a fini par lui même couler sa boite avant d'en partir, et de nos jour il ne reste pas grand chose de l'ancienne gloire de Borland, à part Delphi/C++Builder à ce jour chez Embarcadero, c'est toujours un bon produit mais désormais dans un marché niche.

Philippe Kahn est arrivé cependant à bien rebondir après, il a créé plusieurs startups qu'il est arrivé à chaque fois à vendre pour bon prix.

[Christophe]

Access n'est pas un mauvais produit. Il conviendra très bien aux petits projets et aux non informaticiens, et pourra être un frontend pour des projets un peu plus sérieux utilisant SQL Server (mais c'est pas sa plus large utilisation).

[yento]

MariaDB est en petite forme, la base n'arrive clairement pas à s'imposer au niveau actuel du marché de l'emploi.

MySQL a disparu il y a presque une decennie juste apres l'acquisition par oracle. Les distributions linux ont remplaces le package par MariaDB.
Quand vous faites un "apt-get install mysql", ca installe MariaDB.

MySQL est toujours vendu et supporte par Oracle, mais pratiquement aucun developpeur/DBA va aller s’enregistrer sur le site web oracle et telecharcher le package officiel, plutot que d'installer le package qui vient avec la distribution (MariaDB).

En ce qui me concerne, MySQL et MariaDB devraient etre fusionnes en une seule ligne. La distinction n'a pas lieu d'etre.



Pour le NoSQL, est-ce que ce serait possible d'ajouter cassandra et elasticsearch?
Et peut etre RDS pour le SQL et RedShift pour le NoSQL. Si AWS a perce en France?

Pour information, de l'autre cote de l'ocean, pratiquement tous les editeurs (moins de 500 personnes) sont passe a RDS, et autres databases qui vient avec le cloud. Elles ne gerent plus leurs infrastructure ni leurs bases de donnees. Elles cherchent specifiquement des gens qui ont de l'experience avec RDS, ca ne suffit pas d'avoir de l'experience avec postgresql/mysql.

[Fleur en plastique]

MySQL a disparu il y a presque une decennie juste apres l'acquisition par oracle. Les distributions linux ont remplaces le package par MariaDB.
Quand vous faites un "apt-get install mysql", ca installe MariaDB.

Faux. Sur mon Ubuntu, un apt-get install mysql installe MySQL 8.0.

Si certaines distributions ont effectivement remplacé MySQL par MariaDB comme par exemple Debian, il est faux d'affirmer que MySQL n'est plus disponible dans les dépôts. Et Ubuntu n'est pas "une petite distribution". Ubuntu propose ainsi dans les dépôts MariaDB et MySQL.

C'est d'autant plus pertinent que MariaDB n'est plus un drop-in replacement de MySQL, chacun ont suivi des voies différentes et les deux systèmes sont maintenant incompatibles.

MySQL est toujours vendu et supporte par Oracle, mais pratiquement aucun developpeur/DBA va aller s’enregistrer sur le site web oracle et telecharcher le package officiel, plutot que d'installer le package qui vient avec la distribution (MariaDB).

Faux. Il n'est absolument pas nécessaire de s'inscrire pour télécharger MySQL directement, même si Oracle essaye d'inciter à l'inscription, le lien "No, take me to the download" est tout de même bien visible.

De plus, ce téléchargement permet d'ajouter le support de MySQL dans la distribution cible et donc d'assurer une mise à jour des paquets comme si le paquet était natif à la distribution pour les distributions pour lesquelles il ne l'était pas.

Je n'aime pas Oracle non plus, mais prétendre que MySQL n'existe plus depuis dix ans relève du FUD.

[yento]

Faux. Il n'est absolument pas nécessaire de s'inscrire pour télécharger MySQL directement, même si Oracle essaye d'inciter à l'inscription, le lien "No, take me to the download" est tout de même bien visible.

Faux. Les liens partent et reviennent selon la volonte d'Oracle. S'ils sont present aujourd'hui ca ne veut pas dire que tu pourras y compter demain.

Je me souviens tres bien de MySQL apres l'acquisition par Oracle. Je donnais des cours de SQL a l'epoque.
On debute doucement, telecharger et recompiler MySQL avec des options en plus.

Et bien ce n'etait pas possible, parce que tous les liens avaient ete supprime par Oracle. Il faut s'enregister pour telecharger.

[foetus]

Faux. Sur mon Ubuntu, un apt-get install mysql installe MySQL 8.0.

> dpkg -i mysql-apt-config_0.8.12-1_all.deb
> apt-get update
> apt-cache policy mysql-server // check MySQL version

mysql-apt-config est 1 script qui permet de configurer les dépôts donc @yento a raison

[Christophe]

MySQL est toujours dans les dépôts Ubuntu, mais la tendance est son remplacement par MariaDB.

L’édition community est effectivement téléchargeable sur le site mysql.com sans enregistrement

Le deb dont tu parles Foetus, permet de sélectionner sa version, va installer le source.list de Mysql. Si tu télécharges la version bundle, tu as tous les .deb dans un fichier tar.

[Bloodymary]

C'est pas vraiment classé RAD, ce qui est classé RAD c'est des outils plus génériques comme par exemple Delphi, C++Builder, Lazarus, Windev, ...
Parce qu'Access n'est pas fait pour développer n'importe quel type d'applications, c'est juste une suite de générateurs ( création de bases, écrans, états, requêtes, ... ) pour les bases de données.


....

Le RAD vendu par Microsoft etait VB
Sachant que tu peux faire la meme chose a 99% avec Access, je ne vois pas trop en quoi ce ne serait pas un RAD...

[commandantFred]

RAD ne veut pas dire grand chose...
C'est un segment de marché ? Access est packagé dans un pool d'outils bureautiques et... fait du RAD ! C'est un RAD de bureau ! L'intégration de VB dans chaque produit Office était un choix audacieux. Peut être un RAD doit-il permettre de livrer un produit avec un setup que le client ne peut pas reverse-engineer (décompiler), peut-être pas.

Access, ce n'est pas que des générateurs, il y a de l'IHM sans code, un grid extraordinaire capable d'arborescence, très rapide et fluide, qui copie colle par bloc vers excel. Ce grid n'est pas un contrôle à drag dropper sur un form. C'est un type de form interchangeable qui se bind sur son dataset tout seul. Cette grille n'est pas directement adressable par code, elle n'est pas insérable dans une boucle d’événements, elle possède la sienne et on ne peut pas facilement lui ajouter du code.

Certaines vieilles grilles de VB6 sont encore là - il suffit d'ajouter leurs références dans le projet - mais elles sont moins bien finies. Par contre, on peut les insérer dans un un form et gérer leurs évènements. Les librairies de référence sont à l'image de la carrière de VB qui a été le langage les plus utilisé au monde, innombrables...

Le générateur d'état est l'un des plus réussis que j'aie vu. Pas très sophistiqué, au contraire, plutôt simple avec une précision graphique et un rendu de souris/clavier très réussis et une extensibilité VBA.

Les générateurs s'appellent des wizzards

et toujours pas de picture box ou canvas....

[Emmanuel R]

Je suis assez étonné de ne pas voir énoncées les bases de données Cloud, et de ne se concentrer que sur les On-Premise.
Puisqu'on en est à parler des bases de données les plus demandées et les mieux payées, pourquoi ne pas évoquer ce petit mouvement vers le Cloud, qui est censé apporter robustesse et scalabilité dans les environnements, et dont je serais très curieux de l'évolution de la part de marché. Chez mes anciens clients, je vois des projets de migration Oracle vers Redshift, Teradata vers Big Query, et une grande majorité qui est en train de mettre en place Snowflake.

Si on décide de parler seulement des BDD On-Premise, il serait judicieux, pour les jeunes diplômés qui observent ces salaires avec des grands yeux ébahis, d'énoncer qu'il n'est pas impossible que ces technologies soient sur une pente descendante. Et que tu pourras peut-être trouver plus facilement, avec un salaire équivalent si ça n'est meilleur, sur du Snowflake / BQ / Redshift / Whatever.


Par contre, j'ai comme la petite intuition qu'Access restera longtemps en belle position
Cependant, l'étude est biaisée. Ce n'est pas pour ses capacités mirobolantes en traitement de données qu'Access est devant, mais parce qu'il est couplé à une compétence fonctionnelle importante.

Toujours un conseil à un jeune diplômé : ne passe pas des jours à apprendre Access et postuler en finance en espérant toper un 5k€ avec juste ces compétences techniques, je ne suis pas sûr que ça te soit d'une grande utilité.


Concernant l'étude en elle-même : elle me semble légèrement décousue, intégrer les technologies d'actualité avec une ventilation on-premise/Cloud ne lui ferait que le plus grand bien et serait d'utilité publique. Savoir qu'Access / MongoDB / DB2 etc marchent bien, c'est cool, mais c'est sur combien d'offres en volume en comparaison des années précédentes ? Le graphique d'évolution montre un pourcentage dans un mouchoir de poche sur quelques technos sélectionnées d'une offre dont il est très possible qu'elle soit sur le déclin.

[Christophe]

Je suis assez étonné de ne pas voir énoncées les bases de données Cloud, et de ne se concentrer que sur les On-Premise.

Ca ne change pas grand-chose, les grands acteurs Cloud offrent des instances des bases de données présentées.

[Emmanuel R]

Oh, Mea Culpa, ces BDD On-Premise à la base en effet, ont désormais des instances dans le Cloud.
Mais il me semblait avoir lu que c'était une étude sur les bases de données les plus demandées et les plus payées, et pas sur les bases de données qui étaient bien ancrées en 2015 et qui existent encore aujourd'hui

De fait, et afin de garder une certaine cohérence dans l'étude, et surtout ajouter de la valeur, il me semblerait pertinent d'y inclure les acteurs qui ont émergé ces dernières années.
Il ne me semble pas voir dans l'étude des noms tels Redshift (Amazon), Big Query (Google), Azure SQL Database (Microsoft), Snowflake (éponyme avec une introduction en bourse remarquée en septembre dernier) ?

On rappellera que, notamment, les offres Redshift, Big Query, Azure s'intégrent très bien avec leurs autres produits Amazon/Google/Microsoft pour l'analytics, le stockage froid, etc, ce qui propulse leur utilisation et les rend plus attractives en comparaison d'une BDD classique.
Il y a un avantage concurrentiel, dont il serait très intéressant de voir si cela se retrouve dans les offres.

Au fait, on remarquera que pour cette thématique Cloud, Microsoft ne met pas en avant une instance de SQL Server, mais bien Azure SQL Database.
Alors, je ne sais pas si ça change grand chose (pour paraphraser), mais si Microsoft n'a pas recyclé SQL Server pour ces usages, j'imagine qu'il y a bien une raison.

Attention, hein, je ne crache pas sur les On-Premise, elles ont apporté beaucoup et continueront pendant quelques temps encore.
Ce qui me dérange, c'est qu'il y a un pan du marché qui est totalement occulté et c'est très dommage car l'étude perd de son exhaustivité.

[Christophe]

Au fait, on remarquera que pour cette thématique Cloud, Microsoft ne met pas en avant une instance de SQL Server, mais bien Azure SQL Database.

Sauf que :

Azure SQL Database est basé sur une architecture de moteur de base de données SQL Server.

source : https://docs.microsoft.com/fr-fr/azu...ier-hyperscale

Pour redshift, je ne connais pas, mais ça s'oriente autour d'Amazon RDS qui utilise en moteur de base de données au choix leur base interne Aurora, PostGreSQL, MySQL, MariaDB, Oragle, ou SQL Server toutes évoqués ici sauf Aurora. Ce n'est pas un SGBD mais une surcouche plus vaste, le sujet évoque les SGBD, pas leur surcouches.
Big Query de Google est un service web qui va faire des requêtes, pas un SGBD proprement dit.
Snowflake c'est du datawarehouse as a service, ils ne fournissent pas leur propre SGBD, ils fournissent du S3, de l'Azure, et du Google Platform. Leur surcouche doit apporter une valeur ajoutée pour ceux en ayant l'utilité mais encore une fois c'est au dessus des SGBD.

Il s'agit ici de services au dessus des SGBD, qu'il va falloir bien-sûr maitriser pour utiliser du cloud, mais qui requiert avant tout la maitrise du SGBD.

Par rapport à tes remarques, un nouveau métier est apparu : data scientist. Ce dont tu parles concernera plutôt ce type de poste je pense. Ce sujet pourrat effectiement être repris sur un autre poste sur les solutions big data.

[Emmanuel R]

Le sujet évoque l'emploi, la demande, et le salaire.

Emploi développeur 2020 : les bases de données les plus demandées et les mieux payées

Il convient de se demander qui sont les destinataires de cette étude.
Pour ma part, quand on m'évoque "les bases de données les plus demandées", et en travaillant dans la Data, je me sens concerné par l'étude car je les utilise au quotidien, tant en alim qu'en restit.
Et oui, je trouve que l'étude n'est pas exhaustive. On peut parler de "Développeur BI", "Data Engineer" (des métiers orientés développement, cf le titre). On peut aussi penser aux usages en tant que Data Analyst. Or, je n'ai pas vu de disclaimer indiquant que cette étude occultait les métiers de la Data, qui pourtant utilise grandement les bases de données (et de plus en plus les Cloud). Tant sur la partie modélisation, alimentation que restitution.

Pas besoin d'être dans un cadre Big Data / Data Scientist pour rencontrer ces bases de données : les métiers de la Data suffisent.

Et pour les surcouches, j'imagine bien en entretien :

- Pour nos usages, nous alimentons une base de données Snowflake
- Ah oui mais Snowflake c'est pas une base de données, ils passent par du Azure, du S3 et du Google Platform
- OK, mais vous pouvez l'alimenter ?

Ou encore :

- Pour nos usages, nous alimentons une base de données Big Query
- Ah, alors je vous arrête tout de suite, c'est pas une base de données, c'est un service web
- Ok, mais vous pouvez l'alimenter ?

Vu ?
Avoir une approche puriste des SGBD sans prendre en compte la réalité du marché, ça ne me semble pas très pertinent pour une étude qui se veut objective.

[Christophe]

Si c'est pour de l'alimentation, ou est la difficulté ? Dans l'exemple de Snowflake c'est pour du big data, donc pour un poste de data scientist ou équivalent. Si il est pas foutu de faire une requete en insertion ...

Dans l'exemple présenté, il n'est pas spécifiquement demandé de compétence en développement SGBD, objet de ce fil. c'est aussi l’intérêt du datawarehouse-as-a-service, présenter une abstraction technique pour les opérateurs de big data.

Le sujet parle des bases les plus demandées dans le cadre d'un poste de développeur. Au développeur on va lui demander soit de savoir attaquer et utiliser un SGBD x ou y (voire d'avoir des compétences DBA pour du devops), soit d'utiliser un webservice, qu'il soit interne, cloud qu'il soit fourni par Snowflake ou autre, ce n'est pas le sujet.

[Emmanuel R]

Dans l'exemple de Snowflake c'est pour du big data,

Non, pas seulement.

donc pour un poste de data scientist ou équivalent

Non, pas seulement non plus.

Le sujet parle des bases les plus demandées dans le cadre d'un poste de développeur.

Data Engineer, Développeur BI => Ce sont des métiers orientés développement.

Question subsidiaire : dans le jeu de données utilisé pour l'étude, est-ce que les offres Data ont été retenues ? Si oui, il est nécessaire de considérer les Snowflake et consort, qui, à l'usage, vont concurrencer les usages Data d'un SQL Server, d'un Oracle, etc.

Au développeur on va lui demander soit de savoir attaquer et utiliser un SGBD x ou y (voire d'avoir des compétences DBA pour du devops), soit d'utiliser un webservice, qu'il soit interne

Précisément ce qu'on va demander à un Data Eng', Développeur BI, Data Analyst pour la couche SQL, Data Scientist, et tous les métiers de la Data.

[Pierre Louis Chevalier]

Comme expliqué dans l'annonce, cette étude est basée simplement sur 20 000 offres d'emploi.
C'est pas parce qu'une technologie fait le buzz qu'elle apparait aussitôt dans les offres, surtout en France ou l’adoption des technologies de niche est souvent encore plus lente voir inexistante..
Si je prends l'exemple de l'étude langages, qui est plus simple à analyser :
- Il y a eu il y a 10 ans un gros buzz sur RoR, et à l'arrivé on a quoi : 0,8%
- Il y a eu un gros buzz sur Go, surtout aux USA, et en France à l'arrivée on a quoi : 0,7%
- Depuis un an il y a un certain buzz sur Julia, et à l'arrivée il y a quoi dans les offres d'emploi : Rien, donc du coup rien non plus sur l'étude.

Donc sur les nouveaux produits SGBD / Cloud, ou les startups qui existent depuis moins d'un an il n'y a pas forcément assez d'incidences, alors qu'il y a plus de 1000 résultats sur les SGBD plus traditionnels. Anomaly, qui a fait l'étude, ne peut pas "inventer" des résultats si dans les offres d'emplois il y a pas de matière, par contre certains produits comme Redis apparaitraient peut être s'il baisse ses "seuils".

Après il y a d'autres moyens d'essayer de savoir si des technologies sont utilisées ou pas, et il y a des études qui sortent mais basées sur d'autres sortes de données (Github, etc), mais ici dans ce cas précis c'est basé sur les offres d'emploi et il y a généralement un train de retard par rapport aux nouvelles technologies qui font le buzz sur le web.