Discussion :

[Ikebukuro]

Amis DBA bonjour,

Je me pose une question : pour un DBA Oracle, est-ce plus simple de se former sur SQL Server ou PostgreSQL?
Cela fais plusieurs mois que j'essaye de me mettre en auto-formation à SQL Server et ce n'est pas évident, du moins pour moi, les concepts sont éloignés d'Oracle (Tables clustered, différence User/Schéma...), je ne connais pas PowerShell alors qu'il parait que c'est très utilisé en plus de T-SQL.

En discutant avec un DBA Sybase, il me confirme cette analyse, tout comme il me dit que passer de SQL Server (Windows) à Oracle (Linux/Unix) n'est pas simple car ce DBA en général vient du monde Windows et passer à Linux ne se fera pas sans douleur.

Bref, je dois m'obstiner sur SQL Server ou plutôt me positionner comme DBA Oracle/PostgreSQL?

Il va de soi que je ne compare pas les qualités techniques de SQL Server et de PostgreSQL mais quelle base sur les 2 est plus facile à maîtriser pour un DBA Oracle?

Un gros merci pour vos réponses.

[rouardg]

Bonjour Ikebukuro,

mais quelle base sur les 2 est plus facile à maîtriser pour un DBA Oracle?

Personnellement, je suis bien incapable de répondre à ta question.

Mais je crois que la véritable question est plus dans :

Bref, je dois m'obstiner sur SQL Server ou plutôt me positionner comme DBA Oracle/PostgreSQL?

Si tu veux te positionner, c'est pour répondre à un besoin. Lequel ? Celui de ton employeur ? Celui de tes clients au cas où tu serais consultant ?

Pour ma part, je dirais que si tu as du temps pour t'autoformer, et à moins de vouloir devenir ce qu'on appelle un polyglotte de la base de données (concept plus appliqué à l'étranger qu'en France où l'on demande aux DBA de connaître un peu de tout : SQL Server, Oracle, PostgreSQL, MySQL ou MariaDB, DB2...), moi je pense qu'il est plus judicieux de se former sur des sujets plus porteurs comme le NoSQL, le Big Data avec entre autre le cluster Hadoop, et le Cloud.

Mais je comprendrais que ce genre de technologies ne soit pas ce que tu souhaites faire.

En tout cas, elles ont le mérite de contribuer à son employabilité. Dans le monde du travail actuel, rester cantonné aux SGBDR me semble dangereux pour son avenir.

Mais désolé d'être sorti du cadre de ta discussion.

[Ikebukuro]

Merci pour la réponse.
Je vais quand même voir PostgreSQL, acheter un livre, installer une VM et voir si c'est plus simple que SQL Server.

[rouardg]

Bon courage à toi alors. Cela va te prendre pas mal de temps, car même si l'on a déjà acquis pas mal de connaissances au contact d'autres SGBD, il faut quand même aborder pas mal de choses.

Bien entendu, tout dépend de ce que l'on souhaite couvrir, mais les sujets sont nombreux :
- installation, paramétrage
- architecture
- administration courante
- sauvegarde / restauration
- haute disponibilité : fonctionnement en cluster, bases de secours...
- tuning d'instance, tuning SQL

et bien sur s'approprier tous les outils de la base de données sur laquelle on se forme.

[rouardg]

Et je me permets de réitérer mon conseil : à un moment donné, il faut s'intéresser à d'autres technologies, notamment le NoSQL et le Big Data, tout cela dans un environnement Cloud.

Car ce sont des mondes très vastes, auxquels on ne peut pas échapper à un moment donné.

Moi j'ai arrêté de faire de l'Oracle début 2018, pour aller sur du cluster Hadoop. Et je peux te dire que l'on se prend vite des claques et que l'on se sent vite "has been" face à de jeunes Datascientists qui te parlent dans leur jargon de Python, Anaconda, Notebook Jupyter, Numpy, Pandas, ML...

Idem face à un cluster Hadoop qui est une véritable Stack logicielle, et qui est difficile à maitriser dans sa globalité.

Donc poursuivre sur les SGBDR, oui. Mais ne pas rester cantonner à cela.

[Ikebukuro]

A nouveau, un gros merci pour tes conseils

[Waldar]

Idem face à un cluster Hadoop qui est une véritable Stack logicielle, et qui est difficile à maitriser dans sa globalité.

Et surtout parce que la techno de base c'est quand même pas la panacée (pour rester poli).
Hadoop va mourir et sera remplacé effectivement par les stockages AWS S3, Azure BLOB et Google Storage (dans le cloud ou sur site).

[Ikebukuro]

Merci Waldar pour ton retour, je me doutais bien que les technos NoSQL n'étaient pas matures au point de savoir quel outil va supplanter les autres et devenir un standard; j'ai bien fait d'attendre

[vanagreg]

Ca fait 10 ans qu'on nous dit que le métier de DBA est en danger, que les SGBD vont périr en faveur du NoSQL. Lol, je pense que je serai en retraite avant que cela ne se produise.

[rouardg]

Hadoop va mourir et sera remplacé effectivement par les stockages AWS S3, Azure BLOB et Google Storage (dans le cloud ou sur site).

Je ne sais pas si Hadoop va mourir, mais il est vrai que certains utilisateurs essaient de s'en passer.
Au delà de la complexité de la plateforme et de ses (trop ?) nombreux composants qui nécessitent pas mal de temps pour se former dessus et apprendre à les maitriser, la distribution d'Hadoop a un peu de mal à survivre.

On a ainsi vu :
- IBM arrêter de distribuer son IBM BigInsights
- Hortonworks se faire racheter par Cloudera
- MapR se faire racheter par HP Enterprise

A cela s'ajoute la fin de support de la distribution HDP 2.6 d'Hortonworks, obligeant les clients on Premise à migrer soit en HDP 3.1, soit à migrer sur Cloudera, ou bien à adopter une autre solution.
Et dans le Cloud, idem avec des solutions comme MS Azure HD Insight dans sa version 3.6 qui s'appuyait sur de l'Hortonworks, et qui va nécessiter des migrations puisque le support étendu va bientôt s'arrêter.

En fait, la difficulté des ces entreprises, c'est de survivre. Car il y a actuellement tellement de solutions et d'éditeurs logiciels dans le Big Data et le NoSQL qu'à un moment donné, il va falloir que le marché se concentre et se réduise en termes d'acteurs.
Si des sociétés comme Hortonworks et MapR ont eu du mal à survivre, c'est parce qu'elles ne vendent que quelques logiciels, dont une distribution d'Hadoop.
Les acteurs du Cloud eux, ont des centaines de services à proposer.

[rouardg]

je me doutais bien que les technos NoSQL n'étaient pas matures au point de savoir quel outil va supplanter les autres et devenir un standard; j'ai bien fait d'attendre

Oui, mais il ne faut pas trop attendre non plus. Car l'effort personnel est assez considérable pour passer à ces autres technologies, qu'elles soient matures ou pas.
A un moment donné, il ne faut pas penser qu'à l'aspect technique.
Pour moi, il faut aussi essayer de préserver son employabilité.

[rouardg]

Ca fait 10 ans qu'on nous dit que le métier de DBA est en danger, que les SGBD vont périr en faveur du NoSQL.

A mon humble avis, ce n'est pas le NoSQL qui risque de mettre en péril les SGBDR, car ces 2 types de bases, qui n'ont rien à voir, ne répondent pas aux même besoin.

Et puis il y a un tel parc de SGBDR dans les entreprises que le boulot ne va pas s'éteindre du jour au lendemain.

Non, moi je pense plutôt que le danger, c'est de voir ton boulot partir à l'étranger.

Nous avons tous connus cette période où on a envoyé à l'étranger, notamment en Inde, le boulot fait auparavant en local par les administrateurs système, les admins réseau, les DBA....C'est ce qu'on appelle l'offshore.

Et bien la nouvelle tendance (mais je ne sais pas jusqu'à quel point cela va se développer), c'est de maintenant envoyer ces mêmes boulots en Europe.

Je pense notamment à une grande entreprise française qui a remercié tous ses DBA Oracle prestataires localisés en France, pour des contrats locaux signés dans des pays tels que l'Espagne ou le Portugal.

Là encore, il ne s'agit pas de technique, mais de réduire toujours et encore les coûts pour les clients, et de maintenir son employabilité pour ceux qui travaillent chez ces clients.

[vanagreg]

Je pense notamment à une grande entreprise française qui a remercié tous ses DBA Oracle prestataires localisés en France, pour des contrats locaux signés dans des pays tels que l'Espagne ou le Portugal.
Là encore, il ne s'agit pas de technique, mais de réduire toujours et encore les coûts pour les clients, et de maintenir son employabilité pour ceux qui travaillent chez ces clients.

Oui malheureusement c'est le risque. Oracle qui avait des bureaux en Europe de l'ouest, dont l'Espagne, les a fermés pour sous-traiter en Roumanie. La qualité du support s'en ressent. Faire des centres de service multi-base de données est aussi à la mode, mais le problème c'est qu'on demande aux DBAs dans ces centres de connaitre plein de bases de données différentes, et au final ils ne sont spécialistes en rien, en fait c'est de la débrouillardise. Ca fait plusieurs boites que je fais comme ça où des clients sous-traitent à de tels centres et là c'est choquant parfois le niveau d'incompétence du gars que tu as en face.

Mais on est d'accord que varier ses compétences n'est pas une mauvaise idée. Dans une précédente boite ils avaient eu l'idée de partir sur du Cassandra pour certaines parties du logiciel. Le problème c'est le recul, et également les compétences, car au final les spécialistes ne se bousculent pas. Au final tu paies très cher les boites ou consultants pour un produit "gratuit". Je ne sais pas si ça a fini par se faire, car je suis parti avant que ça se finalise.

[SQLpro]

PostGreSQL est un marché minuscule et terme de business par rapport à SQL Server et le restera vu ses défauts de conceptions qui le rend inapte aux performances comme aux bases de données volumineuses ou fortement concurrentielles (nombreux utilisateurs). Cela dépend donc de ce que tu veut faire :

• te faire plaisir en apprenant une techno
• pouvoir vendre du services.

En outre, le free soft a la malheureuse tendance à être très peu rémunérateur... Pourquoi payer du service si je paye pas pour les licences ?
En conclusion, non seulement tu auras plus de boulot, mais tu sera mieux payé en optant pour SQL Server plutôt que PostGreSQL

Pour les différences :
http://mssqlserver.fr/postgresql-vs-...s-pour-le-dba/
http://mssqlserver.fr/postgresql-vs-...es-avec-count/
http://mssqlserver.fr/postgresql-vs-...ed-comparison/

A +