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...
2 |
0 |