Discussion :

[CaptainDangeax]

Ou bien tu as lu trop vite, car même si sa construction de phrase n'était pas parfaite, il affirmait justement la même chose que toi, que les commandes Linux étaient plus complètes.

Oups, j'ai lu trop vite, influencé par le début de la comm...

[Glutinus]

Il ne faut pas oublier PL/SQL sur les projets. A moins que je me trompe, le PL/SQL est incompatible sur SQL Server (transac SQL)

Les projets de migration, ça existe...

[StringBuilder]

Et encore, "migration" est un grand mot.

Le T-SQL n'est pas si différent du PL/SQL.

Mise à part les triggers de type "for each row" qui n'existent pas sous SQL Server (et c'est un bien), il n'y a pas de différence fondamentale la plupart du temps.
=> Oui, il faudra repasser dans tous les scripts pour modifier la syntaxe…
=> Mais pas spécialement plus que dans le code des programme où les utilisateurs auront probablement utilisé "DUAL" et autres "=(+)" à toutes les sauces…

Ca représente du boulot… Mais même pas sûr que ça coûte le prix de la différence de licence annuelle entre Oracle et SQL Server !

[amirouche95]

Oracle avec sa politique appliquée sur les prix du Build en te proposant des prix déjà cher mais restant raisonnable, nous dupe rapidement sur le RUN avec les audits, le l'obsolescence du matériel ..etc
Perso je conseil plus Oracle pour nos clients

[SQLpro]

Comme je le disais et comme c'est marqué dans l'article, Peter Gulutzan est senior technical lead chez MySQL et s'occupe d'implémenter un SQL décent, proche de la norme pour MySQL… C'est donc quelqu'un qui est au cœurs de la R&D de MySQL…. ALors il doit focrément être au courant de nombreux mois (voir années) à l'avance de ce qu'il y aura dans une release… A moins que Oracle (la maison mère) ait développé une nouvelle technique de codage qui permet en quelques heures d'implémenter et tester de nombreuses fonctionnalités nouvelles dans un SGBDR sans en avertir les responsables….

A +

[phc2908]

Dans ma boite, on vend des logiciels médicaux et à l'origine (il y a fort, fort longtemps sous DOS ou en 16bits Windows) nous utilisions des fichiers DBASE mais vu le niveau de fiabilité du bouzin (surtout à cause des gros bugs de pile IP sous 95), nous nous sommes tournés vers Oracle et cela fonctionnait super bien, fiable, simple, robuste mais déjà des politiques tarifaires et commerciales pourries qui changeaient presque tous les ans.

Lorsque j'ai tout réécrit pour passé en 32 bits, j'ai viré DBASE et ai commencé à intégrer SQSErver (la 6.5 à l'époque) et aujourd'hui nous supportons les deux mais la Oracle se fout visiblement complètement de ses petits clients et leurs tarifs ne se sont pas arrangés et pendant très longtemps nous sommes restés à un rapport 80 / 20 en faveur d'Oracle mais à force de prendre leurs clients pour des pigeons, le vent a tourné. En plus de cela, de version en version, tout est de plus en plus lourd et complexe et mon absence de formation continue dans ce domaine (ben oui, comme dans beaucoup de boîte, c'est considéré comme de l'argent gaspillé... heureusement qu'il y a Internet, les forums et que l'expérience s'accumule petit à petit)

Depuis quelques années nous migrons donc en masse nos clients de Oracle vers SQLServer pour des raisons très différentes :
1- une raison rationnelle de coût : SQLServer est moins cher et surtout notre application supporte très bien les versions Express, gratuite (faible volumétrie de données, peu d'utilisateurs simultanés)... donc ça coûte encore moins cher
2- une rationalisation des moyens techniques : il faut éviter de démultiplier les types de plateforme et l'argument 1 fait qu'on ne conserve que SQL Server... seuls nos clients vraiment attachés à Unix / Linux continuent encore de préférer Oracle.
3- une raison irrationnelle : SQLServer c'est graphique et donc c'est simple : oui oui je l'ai bien ressenti celui-là comme argument. Les décideurs pensent A TORT que tout est plus simple parce que tout (ou presque) est graphique et qu'ils pourront en même temps se passer du salaire d'un vrai DBA. Grave erreur dont certains se mordent les doigts le jour où de vrais problèmes apparaissent mais bon...

J'ai développé moi-même l'outil de transfert entre Oracle et SQLServer (il marche dans les deux sens) et cela marche très bien car je me suis toujours assuré d'une totale cohérence de structuration entre les deux types de bases.

Là où cela se complique c'est pour les procédures stockées. J'avoue honnêtement que lorsqu'on a développé pendant des années en PL/SQL, passer à SQLServer, c'est une abomination : fini les exceptions dans les fonctions, fini le code ultra bien structuré (ça devient vite pourri si on n'est pas carré dans sa tête quand on développe et si je me fait un point d'honneur à toujours l'être, tous les développeurs ne le sont pas), fini les packages qui permettent de regrouper son code et ne montrer que ce qui est utile, fini le "for each rows" des trigger qui compliquent terriblement leur développement, fini la simplicité de certains outils en ligne de commandes comme SQLLoader (ben oui c'est graphique sous SQLServer donc faut tout faire graphiquement là où un simple fichier de contrôle en ASCII suffit pour ligne de commandes), etc... et SURTOUT fini la possibilité de wrapper son code pour s'assurer que les clients ne voient en clair le code qu'on livre. Dans certains cas, masquer son code "métier" est très utile pour des raisons de sécurité.

J'ai eu à faire une très grosse migration comme celle là pour un client qui avait beaucoup d'interfaces avec d'autres systèmes informatiques et à traduction bête et méchante de code, j'ai grosso modo divisé par 10 les performances dans certains cas (et le pire : en passant d'un vieux Oracle 8.1 à un SQL Serveur 2008R2 !). Il a ensuite fallu tuner tout cela pour que cela redevienne supportable mais là, il a fallu faire appel aux DBA et beaucoup de temps. Il faut admettre que les processus internes d'optimisation d'Oracle sont très efficaces et dispensent de beaucoup de travail d'optimisation quand on a des besoins simples.

Alors que dire. Pour moi Oracle demeure largement supérieur à SQL Serveur techniquement mais ça ne les sauvera pas s'ils continuent avec leur politique commerciale aussi moisie (pour rester poli). On a déjà vu des leaders techniques se casser la gueules à cause de leur incapacité à gérer correctement l'aspect commercial.

Ceci était juste le témoignage d'un utilisateur des deux bases...

[SQLpro]

...En plus de cela, de version en version, tout est de plus en plus lourd et complexe et mon absence de formation continue dans ce domaine (ben oui, comme dans beaucoup de boîte, c'est considéré comme de l'argent gaspillé... heureusement qu'il y a Internet, les forums et que l'expérience s'accumule petit à petit)

Hélas rien ne remplace une bonne formation...

Depuis quelques années nous migrons donc en masse nos clients de Oracle vers SQLServer pour des raisons très différentes :
1- une raison rationnelle de coût : SQLServer est moins cher et surtout notre application supporte très bien les versions Express, gratuite (faible volumétrie de données, peu d'utilisateurs simultanés)... donc ça coûte encore moins cher
2- une rationalisation des moyens techniques : il faut éviter de démultiplier les types de plateforme et l'argument 1 fait qu'on ne conserve que SQL Server... seuls nos clients vraiment attachés à Unix / Linux continuent encore de préférer Oracle.

Sachez que depuis 2017, SQL Server est disponible sous Linux, même dans la version Express...

3- une raison irrationnelle : SQLServer c'est graphique et donc c'est simple : oui oui je l'ai bien ressenti celui-là comme argument. Les décideurs pensent A TORT que tout est plus simple parce que tout (ou presque) est graphique et qu'ils pourront en même temps se passer du salaire d'un vrai DBA. Grave erreur dont certains se mordent les doigts le jour où de vrais problèmes apparaissent mais bon...

Tout à fait vrai. Disons simplement que pour ceux qui passent d'Access à SQL Server c'est pratique... Mais pour ceux qui pensent qu'il suffit de cliquer pour administrer au même niveau qu'Oracle... c'est foutu !

J'ai développé moi-même l'outil de transfert entre Oracle et SQLServer (il marche dans les deux sens) et cela marche très bien car je me suis toujours assuré d'une totale cohérence de structuration entre les deux types de bases.

Là où cela se complique c'est pour les procédures stockées. J'avoue honnêtement que lorsqu'on a développé pendant des années en PL/SQL, passer à SQLServer, c'est une abomination : fini les exceptions dans les fonctions,

Sauf que dans la norme SQL cela n'existe pas. En effet une fonction n'a pas à gérer une exception. Par ce que par principe elle ne peut être exécutée de manière autonome et doit être incorporée dans une requête ou une routine. Et dans une requête constatez que vous ne pouvez pas non plus gérer une exception...

fini le code ultra bien structuré (ça devient vite pourri si on n'est pas carré dans sa tête quand on développe et si je me fait un point d'honneur à toujours l'être, tous les développeurs ne le sont pas), fini les packages qui permettent de regrouper son code et ne montrer que ce qui est utile,

Là je vous rejoins, mais constatez aussi que la mode n'est plus aux langage hyper structuré à la Ada dont s'est inspiré Oracle... On est plutôt à la mode java ou PHP... langages assez laxistes ! mais très productifs...

fini le "for each rows" des trigger qui compliquent terriblement leur développement,

Là je ne peut être d'accord... En effet dans un univers ensembliste un déclencheur ligne par ligne donc itératif est une imbécilité qui rejaillit immanquablement sur les performances et tien ne vous empêche de faire du ligne à ligne dans votre déclencheur en implémentant un curseur !

fini la simplicité de certains outils en ligne de commandes comme SQLLoader (ben oui c'est graphique sous SQLServer donc faut tout faire graphiquement là où un simple fichier de contrôle en ASCII suffit pour ligne de commandes), etc...

manque de formation ? Son équivament est BULK INSERT / bcp.exe

et SURTOUT fini la possibilité de wrapper son code pour s'assurer que les clients ne voient en clair le code qu'on livre. Dans certains cas, masquer son code "métier" est très utile pour des raisons de sécurité.

ça existe depuis au moins la version 7 avec la directive WITH ENCRYPTION... Manque de formation ??? De plus depuis la version 2005 vous pouvez chiffrer une procédure stockée qui ne sera exécutable qu'avec un certificat associé à l'utilisateur...

J'ai eu à faire une très grosse migration comme celle là pour un client qui avait beaucoup d'interfaces avec d'autres systèmes informatiques et à traduction bête et méchante de code, j'ai grosso modo divisé par 10 les performances dans certains cas (et le pire : en passant d'un vieux Oracle 8.1 à un SQL Serveur 2008R2 !). Il a ensuite fallu tuner tout cela pour que cela redevienne supportable mais là, il a fallu faire appel aux DBA et beaucoup de temps. Il faut admettre que les processus internes d'optimisation d'Oracle sont très efficaces et dispensent de beaucoup de travail d'optimisation quand on a des besoins simples.

Je pourrais vous citer beaucoup d'exemples contraires... Récemment un POC chez un client nous a montré un x 30 en transposant du code Oracle en SQL Server.... Ce qui n'a pas empêché le client de continuer avec Oracle en disant "oui, mais on maîtrise mieux !

Alors que dire. Pour moi Oracle demeure largement supérieur à SQL Serveur techniquement mais ça ne les sauvera pas s'ils continuent avec leur politique commerciale aussi moisie (pour rester poli). On a déjà vu des leaders techniques se casser la gueules à cause de leur incapacité à gérer correctement l'aspect commercial.

Techniquement il reste peu de chose pour lequel Oracle est supérieur à SQL Server (1). Sur le plan des performances c'est, déjà plié depuis quelques versions. Le côté anormatif d'oracle qui empêche la transposition facile d'un code PL/SQL dans un autre SGBDR a longtemps été le fer de lance de Larry Ellison. Mais maintenant c'est le contraire qui se passe. Oracle perd tellement de client qu'ils pensent enfin à se normaliser afin de capturer les rares et maigres clients qui veulent fuir DB2 ou SQL Server pour aller chez eux ! par exemple comment faire la transposition d'une base SQL Server ou DB2 dont les noms des objets on 128 caractères de longs (norme SQL ?) et bien Oracle a enfin modifié sa version pour accepter cal.
De même pour le multibase (qualifié de "multi tenant"... !) mais il faut payer des licences supplémentaire pour chaque base.
Autre exemple l'imbitable NLS alors que la norme c'est la collation. Oracle vient enfin de s'y mettre...

Mais pour tout ceci c'est hélas trop tard !!!!!

Ce que je constate souvent dans mes audits c'est que les gens qui portent des bases de Oracle à SQL Server, tente de reproduire strictement le même code croyant que le système fonctionne de façon identique... Bien évidement il n'en est rien (un exemple est le verrouillage par défaut qui est optimiste dans Oracle et pessimiste dans SQL Server, oracle n'ayant pas la possibilité de passer au pessimiste, mais SQL Server a, lui, la possibilité de passer à l'optimiste). Récemment je suis tombé chez un éditeur, très con - donc je ne citerais pas son nom - qui vend désormais ses applications sous SQL Server avec des performances lamentables et des blocages et dont le discours consiste à dire :
" c'est beaucoup mieux sous Oracle et ça va plus vite, donc c'est votre faute si vous achetez la version SQL Server "
Alors je lui ai rétorqué que s'il était incapable de fournir une solution fiable et performante pour SQL Server, c'est simplement qu'il était incompétent et dans ce cas on ne la met pas à son catalogue.
Pour comble de malheur je suis en audit dessus et aucune requête sur le serveur ne dépasse 10 ms et il n'y a aucun blocage ni interblocage après une journée complète d'audit avec traces de TOUTES les requêtes sur la production (grand groupe de transports français)... Il a même fait acheté à son client un serveur beaucoup trop puissant (48 CPU, 128 GO de RAM pour une base de 130 Go..., 8 disques SSD...), ce qui fait que globalement le serveur est utilisé en dessous de 5% de ses capacités.
Nous n'avons pas accès au code applicatif, mais il est vraisemblablement farci de curseurs ouvert dans un mode propre à Oracle (qui sur ce sujet aussi est anormatif) et qui pose des problèmes de lenteurs dans l'exécution du code client....

A +

(1) RAC en est une... pas d'équivalent sous SQL Server !

[kedare]

On commence a voir des système assez interessant pour deployer de DB haute dispo sur du Kubernetes, j'ai pu jouer un peu et c'est assez impressionant, quelques exemples avec Helm (Un outil de deploiement pour Kubernetes), une ligne pour avoir un cluster haute dispo :

SQLServer (Sans Helm): https://medium.com/searce/sql-server...e-df442f3da552
MySQL/PXC: https://github.com/helm/charts/tree/...xtradb-cluster
PostgreSQL/Patroni: https://github.com/helm/charts/tree/...ubator/patroni

En tout cas ou a notre enviroenment de staging qui tourne sur SQL Server sur Linux (Sans Kubernetes so far) et on a jamais eu un seul soucis pour le moment. Je pense qu'il y a moyen que ca devienne un moyen assez courant de deployer des bases de données haute dispo dans le future.

[berceker united]

Il ne faut pas oublier PL/SQL sur les projets. A moins que je me trompe, le PL/SQL est incompatible sur SQL Server (transac SQL)

Certes, ce n'est pas une initiative sans désagrément, et je dis bien "désagrément" non "douleur" car ce n'est clairement pas un problème. Entre le coup de rester avec Oracle et prendre des presta qui vont re-pisser du code sans trop réfléchir, il y aura un gain.

Et bahh, MS SQL plus rapide sous Linux que sous WIndows, on aura tout vu. J'aurais jamais pensé à ce point là. *

Je suis tout à fait d'accord que les entreprises ne veulent surtout pas passer leur serveur sous Windows pour raisons de couts de licences, d'habitudes à administrer des serveurs Unix/Linux, ... et je suis de ton avis, MS a eu bien raison de proposer le portage à défaut de ne pas avoir réussi à séduire la suite SGBD + OS

J'ai entendu beaucoup de bien de SQL Serveur sur sa robustesse, sa facilité d'installation et bien d'autres points. Cependant tu as oublié un petit détail, SQL Serveur ne fait pas tourner du PL/SQL. La migration vers SQL Server nécessite dans ce cas une ré-écriture dans certaines situations pour les projets existants. La migration SQL Server ne s'appliquerait que pour les nouveaux projets j'imagine. **

Quand aux DBA préférant AIX à Linux, ça il faudra que l'on m'explique alors que les commandes sont bien moins complètes***.

* Rien d'étonnant à cela, tu enlèves le poids de l'OS tu as un gain.
** Aucun problème sur les projets existant, juste une histoire de ressource. Une base de données ce n'est qu'un tas de sacs avec des choses dedans.
*** Pas de problème, ils iront sur developpez.net pour se former

[voran]

2 ans après cet article et les commentaires prédisant le déclin de la firme Oracle, on constate que même si le chiffre d’affaire à un peu baissé, Oracle est toujours bel et bien présent.
Parmi les clients de la société chez qui je travaille, ceux qui ont abandonnés Oracle (pas nombreux finalement) ont tous choisi PostgreSQL, qui est la grosse tendance depuis 2 ou 3 ans. Et absolument aucun ne part sur du SQL Server / Linux.

[SQLpro]

Cela dépend de la taille et la criticité des bases.... sur des bases de quelques centaines de GO et avec des heures creuses cela est jouable sur PG.... Mais quand tu as des bases de plusieurs dizaine de To ou du 24/24 7/7 à pleine charge, c'est juste pas possible.... D'autant plus que PG est très gourmand en volume de données comparativement....

A +