Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
époque révolue. Oracle est en perte de vitesse sur les SGBDR depuis 10 ans, cela a commencer à se voir réellement que depuis quelques années et vient de s'accélérer depuis 2 ans avec leur absence remarquée sur le cloud ou le "In Memory" combiné à des prix exorbitants de licences et une politique de récupération de gros sous agressive et néfaste (audits de licences...)
exemple, sur le cloud (magic quadrant de Gartner) oracle y est même absent !
http://up2v.nl/wp-content/uploads/20...s-may-2014.jpg
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Il faut dire aussi que la politique d'Oracle s'accomode très mal de la virtualisation qui s'est énormément développée ses dernières années. Oracle considère qu'il faut prendre en considération les caractéristiques physiques du serveur hôte, et non les caractéristiques de la machine virtuelle. Ainsi, si vous avez un serveur à 16 coeurs dont 2 dédiés à une machine virtuelle, Oracle considère que vous devez vous acquitter de 16 licences et non de 2 ! Lors des audits de licences... ça peut faire très mal.
Et je ne parle même pas de ferme de serveurs (où il faut tout additionner).
Il faut aussi dire que le produit SQL Server comprend beaucoup d'addon en plus comme "SQL Server Reporting Services", "SQL Server Integration Services" ... Que par exemple MySQL ou PostgreSQL ne disposent pas, ce qui fait que le prix des compétences deviennent plus élevé.
Moi ce que je retiens de cette étude, c'est deux choses :
1/ Le salaire est proportionnel à la rareté de la compétence.
2/ Malgré la place de plus en plus prédominante de SQL Server, les compétences sur ce SGBD restent très rare (3% contre près de 60% pour Oracle et MySQL)
Ensuite, c'est plutôt la profusion de personnel MySQL qui s'explique par cet aspect "amateur" (ou plutôt, autodidacte).
Quant à Oracle, il profite de sa place de leader du siècle dernier, et de l'abondance de seniors sur le marché qui ont été évincés lors des différentes crises économiques dans les nouvelles technologies.
Enfin, je pense (et cela n'engage que moi, mon expérience n'étant pas forcément significative sur le sujet) qu'en plus de la profusion des ressources pour MySQL et Oracle, le salaire moyen sur ces deux SGBD souffre du manque de compétences SQL des intervenants. En effet, 80% des compétences MySQL sont autodidacte et ne savent pas faire une requête évoluée, quand 80% des compétences sur Oracle ont été formée dans les années 80, alors que le SQL se résumait à "select * from une seule table à la fois" pour la plupart des enseignants.
Du coup, en cas de problèmes de performances sur MySQL, ben... on prend pas au sérieux un gars qui vient avec une casquette "d'expert". Quant à Oracle, on ne va pas faire confiance à un développeur/technicien on va directement taper dans le DBA à proprement parler, dont les forfaits journaliers sont à des années lumières de cette étude.
SQL Server bénéficie à contrario du luxe de compétences jeunes et pointues, car poussé par l'ère de .NET plutôt que de technos vieillissantes ou amateurs que sont le C, Java ou PHP.
Absolument faux, je ne peux pas laisser passer ça.
SQL Server (Express comme Standard, qui sont les deux seules éditions sur lesquelles j'ai une expérience récente) peuvent même être installées en mode silencieux, et sont fonctionnelles immédiatement, sans la moindre interaction avec l'utilisateur.
Si on passe par la GUI d'installation, quelques clics frénétiques sur "Next" sont suffisants, pas le moindre réglage n'est nécessaire pour avoir un serveur fonctionnel.
MySQL, déjà, faut commencer par choisir un mot de passe, le type de stockage pour les bases, et j'en passe. Étapes totalement inutiles pour SQL Server, qui supporte l'emprunt d'identité et n'offre pas le choix entre la peste et le choléra pour le stockage des données.
Quant à l'upgrade de versions...
- Application d'un SP : automatique, silencieux, via Windows Update, aucune action utilisateur requise (mise à part accepter la mise à jour...)
- Installation d'une nouvelle instance (ce qui évite de devoir désinstaller l'ancienne) : géré comme une nouvelle installation, donc next next next.
- Déplacement d'une base d'une instance à une autre d'une version plus récente... Clic droit "sauvegarder" puis Clic droit "restaurer" via la GUI. Ou alors 2 lignes de commande.
- Upgrade d'une instance existante : géré pas assistant durant l'installation, next next next.
Alors ok, l'installation de SQL Server (y compris Express) dure des plombes et on se demande bien ce qu'il fabrique par moment, ça, je te le laisse. Mais pour la complexité... Faudra m'expliquer !
ça ne m'étonne pas trop :
- mysql semble mis dans le même sac que PHP avec des recherches de dev php/mysql pour installer un site web wordpress/Drupal/cie sur un serveur linux pour des coûts très bas.
- oracle est en train de tuer doucement sa base de donnée par son licensing. A l'époque de la virtualisation et du cloud, le licensing de bases de données Oracle est TRES couteux pour un gain finalement faible par rapport aux autres BDD, SQL server en tête
- oracle est en train de tuer doucement mysql, qui tire vers mariadb lentement mais inexorablement, surtout pour le côté cluster actif/actif possible en production.
- sql server bénéficie de l'attrait actuel de l'environnement Microsoft : licenses "faibles", très stable et qui tient très bien la charge, scalabilité & clusters possibles aussi, idem en actif/actif
Les tendances actuelles sont soit à des bases de données qui permettent scalabilité par leur clusterisation.
Donc MariaDB, Cassandra et SQL Server.
Et clairement, on manque cruellement de compétences DBA sur SQL Server, d'où les prix proposés.
On retrouve la tendance.
Ah, dommage, j'aurais dû continuer à faire carrière comme développeur Oracle,
j'aurais gagné plus d'argent qu'à développer pour mes clients (qui disposaient aussi d'Oracle) sur Mysql/Mariadb.
Quand à SQLServer, le prix de la licence m'a dissuadé de développer avec.
Olivier
Cela n'a rien pour m'étonner, SQL Server est devenue la base de donnée la plus populaire et la plus efficace.
Enfin, quand on voit que Oracle n'a pas quasiment évolué depuis 10 ans, qu'ils ne savent toujours pas faire un installeur correct, ni une refonte majeure de leur SGBD, cela n'a rien d'étonnant.
Et je suis déçu qu'ils ne mettent pas les moyens sur Mysql Cluster. Ils n'ont pas commis trop d'erreurs concernant Mysql qui continue de bien évoluer mais pour cela on peut dire merci à la communauté qui s'est beaucoup investie sur le sujet, et à Michael Widenius qui a permis un certaine émulation (même si son machin n'est qu'une coquille vide).
N'empêche que si la seule stratégie d'Oracle est de miser sur Mysql, je me poserais des questions sur l'avenir.
la paye pour ceux utilisant SQL Server est ainsi vus la complexité de configuration. Côté performances à l'utilisation SQL Server est du même niveau que Oracle DB donc il y serait sympa d'avoir enfin un assistant de configuration pour SQL Server et sa part de marché augmenterait de manière significative
Quasiment pas évolué ? Juste des centaines de nouveautés et d'améliorations ! Exadata, Active Dataguard, etc.
10.1 : http://docs.oracle.com/cd/B14117_01/...b10750/toc.htm
10.2 : http://docs.oracle.com/cd/B19306_01/...1.htm#NEWFTCH1
11.1 : http://docs.oracle.com/cd/B28359_01/...9/chapter1.htm
11.2 : https://docs.oracle.com/cd/E11882_01...1.htm#NEWFT107
12.1 : https://docs.oracle.com/database/121...1.htm#NEWFTCH2
Quant à une refonte majeure, pourquoi bouleverser ce qui fonctionne ?
L'architecture d'Oracle a été suffisamment bien pensée dès ses origines, avec notamment son remarquable moteur de consistance multiversion qui a enfoncé la concurrence, pour être capable de tenir 20 ans sans modification majeure.
Il se trouve que la volonté de consolidation, à l'ère de l'infonuagique, concrétisée par le mode multitenant d'Oracle 12c, a justement conduit à la plus grosse refonte de l'architecture depuis Oracle 6 ou 7, tout en préservant l'existant.
Dans les années 80, il ne faut quand même pas exagérer !!
Mais il est vrai que dans les technologies existant de longue date, il y a un risque de ne plus être à la page si on est resté à ce qu'on a appris à ses débuts.
Ça s'applique tout autant à quelqu'un qui aurait débuté en 1995 sur SQL Server 6.5 et n'aurait pas évolué, et probablement à ceux qui ont débuté sur MySQL il y a 15 ans.
Ce n'est donc pas un problème de SGBD X ou Y, mais de mise à jour des compétences.
Quant au fait d'aller chercher un DBA pour les problèmes de performances, ce n'est pas non plus propre à Oracle.
Je pense que c'est dû au fait que les développeurs ne sont généralement pas formés à la performance côté base de données, et au fantasme que le DBA est forcément un cador en optimisation SQL.
Pour ma part, je ne cesse de dire que la compétence en optimisation SQL doit se trouver prioritairement côté développement, puisque ce sont eux qui ont la connaissance fonctionnelle et sont le plus familiers avec les données.
Descend de ton nuage informatique et poses toi la question de savoir pourquoi Oracle est en train de se faire détrôner partout et pourquoi même les administrations passent à Postgresql.
J'ai voulu installer un Oracle en démo il y a un an, mais sans succès. c'est un des rares produits pour lesquels j'ai du renoncer, voir le seul dans mon souvenir.
Pour moi, je trouve inutile cette information pour la seule raison:
Il n y'a pas de profil Développeur MYSQL, soit on est Développeur/Programmeur etc...appelez cela comme vous voulez... et on utilise souvent MySQL comme BD (et on peut passer à SQLSERVER sans pb, paramétrage, Frameworks, etc...) ou on est administrateur DBA /gestionnaires d'exploitation des bases MYSQL.Donc et à mon avis c'est illogique ce que vous racontiez...
Vous êtes juste en train de vous ridiculiser en montrant que vous ne connaissez rien à Oracle, et que vous n'avez aucun argument concret à faire valoir sur l'absence prétendue d'évolutions.
Si Oracle perd des parts de marché, et je ne conteste pas ce fait dans une certaine proportion, c'est pour une raison purement financière.
Ils pratiquent des tarifs qui sont devenus injustifiables.
Et en effet, certaines collectivités se tournent vers Postgresql, tout simplement parce que c'est gratuit.
En revanche, personne n'abandonne Oracle au profit d'un autre produit pour des questions de fonctionnalités.
La difference de paye est due a l'abondance de technicien pour mysql contrairment a sqlserver peu de gens savent s'en servir c'est une usine a gaz ,mais sa reste toute fois deux bons sgbd
Ca n'a rien d'une usine à gaz !
Pour utiliser SQL Server quotidiennement et avoir essayé d'utiliser MySQL quelques fois, je dirais même plutôt l'inverse !
C'est avant tout un problème de clan (oui, je parle bien de clan), à savoir que selon son SGBD de prédilection, on le trouve plus simple (normal, puisqu'on le maîtrise) et on dénigre les autres à la première difficulé (normal, on ne comprend pas pourquoi un truc aussi évident ne marche pas pareil). Il n'y a rien d'objectif dans ce débat, si ce n'est l'analyse pertinente concernant :
- L'abondance des développeurs tournés vers MySQL, qui explique une concurrence accrue
- L'abondance historique de développeurs tournés vers Oracle, corrélé à un recul de part de marché de ce dernier, qui explique la même concurrence
- La rareté des développeurs tournés vers SQL Server, corrélé aux parts de marché grandissantes de ce dernier, qui explique le phénomène inverse
1) Hopwork c'est du freelance, pas du salariat
2) le panel est trop petit pour justifier la véracité des chiffres
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Désolé de te contredire, mais c'est totalement faux....
On peut prendre l'exemple de l'IGN qui était autrefois Oracle (pour son spatial) et est passé à PostGreSQL puis à SQL Server, car le spatial y est conforme à l'OGC ce qui n'est pas le cas du spatial d'Oracle dont le format est propriétaire.
On peut prendre le cas de SAGE qui abandonne définitivement Oracle au profit de SQL Server en utilisant des fonctionnalités qu'oracle n'a pas développé aussi vite comme le FILESTREAM ni fait évoluer comme le FileTable...
On peut prendre le cas d'Eurocopter qui a abandonné Oracle au profit de SQL Server pour sa maintenance Wolrwide car la réplication des données avec Oracle est juste une horreur, là ou elle fonctionne parfaitement en 4 modes différents depuis la version 2000 !
Et j'en ais d'autres en réserve....
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Partager