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).