Discussion :

[Michael Guilloux]

Microsoft vous accompagne dans votre migration d'Oracle vers SQL Server 2017
avec une formation et des licences gratuites

SQL Server 2017 est officiellement disponible depuis le 2 octobre et pour la première fois, le logiciel de base de données de Microsoft ne sera pas destiné uniquement à Windows, mais également à Linux.

Absent du monde Linux, Microsoft n’avait pas donné d’autres choix aux entreprises que celui d’opter pour Oracle, en ce qui concerne les SGBD propriétaires. Maintenant que le géant du logiciel propose une version de sa base de données sur Linux, il a décidé d’accompagner les entreprises dans leur migration d’Oracle sur Linux vers SQL Server 2017 sur Linux. Les organisations peuvent donc dès maintenant planifier leur migration pour bénéficier de licences gratuites, une formation gratuite et des services de migration subventionnés. Microsoft met également en avant un coût total de possession (TCO) qui ne représente qu’une infime partie de celui d’Oracle.

Il faut noter que cette offre ne s’applique pas qu'à Linux. Vous pouvez également en profiter pour migrer d’Oracle vers SQL Server 2017 sous Windows. L’offre comprend des licences gratuites, des services de support pour démarrer votre migration et accéder au cours SQL Server Essentials de Microsoft pour la formation d'administrateur de base de données Oracle. Cette offre vous permettra de découvrir les fonctionnalités clés de SQL Server grâce à des ateliers pratiques et à des démonstrations réalisées par des instructeurs, mais également apprendre à déployer vos applications sur site ou dans le cloud. En ce qui concerne les fonctionnalités de SQL Server 2017, on peut citer parmi les plus importantes :

• l’intelligence artificielle intégrée avec des analyses R et Python ;
• le calcul de score en natif dans T-SQL : une nouvelle fonctionnalité qui vous permet de calculer les scores sur les modèles de machine learning en temps quasi réel ;
• la gestion et analyse des données de type graphe ;
• Adaptive Query Processing : une nouvelle famille de fonctionnalités dans SQL Server qui apportent de l'intelligence aux performances de la base de données. Elle comprend par exemple Adaptive Memory Grants qui surveille la quantité de mémoire utilisée par une requête donnée au fil du temps pour éviter une allocation excessive ou insuffisante de la mémoire, situation qui peut affecter les performances ;
• Automatic Plan Correction : une fonctionnalité qui assure une performance continue en identifiant et en corrigeant les régressions de performance ;
• Machine Learning Server for Hadoop (ex R Server), qui apporte des analyses évolutives basées sur R et Python aux environnements Hadoop et Spark ;
• Power BI Report Server, qui offre une expérience de reporting et de tableaux de bord hybrides en vous permettant de gérer vos rapports SSRS à côté de vos rapports Power BI ;
• etc.

Il faut noter que l’offre est d'une durée limitée. La formation gratuite et les services subventionnés sont disponibles jusqu’à épuisement des stocks ou jusqu’au 30 juin 2018. Vous devez donc vous enregistrer dès maintenant pour vous assurer de bénéficier de l’offre.

Migrez d'Oracle vers SQL Server 2017 (sous Windows ou Linux) et profitez d'une formation et des licences gratuites

Voir aussi :

Pourquoi passer à SQL Server 2017 sur Linux ?
Découvrez le rapport Magic Quadrant de Gartner sur les SGBD

[kilroyFR]

L'idée est tres séduisante mais generalement ceux qui utilisent Oracle font grand usage du PL/SQL (pour codage des procedures stockées) et le gros du boulot de migration ce n'est pas tant la bascule du modele de données (se fait assez simplement) mais plutot le pb de non migration du code applicatif; et ceci est largement redibitoire (tout reecrire en C# ? le travail est colossal sur des gros projets de BDD - on a essayé et la difference de facture ne couvre pas les depenses liées au "portage" du code+tests etc).
Chez nous ca se chiffre en milliers de lignes de code.

Aussi dans ma boite on utilise sqlserver uniquement sur les nouveaux projets (lorsque pas d'existant logiciel) et que le client exige sqlserver (bon, c'est arrivé une fois en 2 ans).
Meme si sqlServer etait gratos (hors presente offre limitée dans le temps) il y aurait malgré tout des couts de migration de code comme on vend plutot a des gros clients (et non pas a des milliers de sites) du coup on fait avec les prix des licences Oracle (qui sont souvent au final derisoires rapportés au cout du projet).

[mattdef]

L'équivalent du PL/SQL en Microsoft est le T-SQL, pas le C#. Et il y a des outils pour convertir tout ça plutôt facilement. Enfin perso j'ai jamais eu de gros problême à ce niveau là

[kilroyFR]

Si je dis ca c'est que nous avons essayé et on etait tres tres tres loin de ce qu'on utilisait avec Oracle. T-SQL ca me ramene il y a 20 ans quand je faisais du Sybase donc le plus adapté c'est certainement plus le C# que T-SQL. Je te parle de 10aines de milliers de code avec utilisation de la plupart des packages DBMS_xxx Oracle (pour lesquels il n'y a pas d'equivalents en T-SQL d'ou l'idee de refaire les equivalents en C# - T-SQL avec ses syntaxes barbares ca te fait devenir aveugle au bout d'une page de code avec tous les symboles cabalistiques du langage).
Je serai curieux de connaitres tes outils miraculeux; je pense que ca tient plus de l'anecdote qu'autre chose (ou alors c'est que tu ne connais que vaguement PL/SQL).
J'ai fais les 2 (Oracle depuis 1997 et SqlServer depuis plus de 2 ans).
Meme PostGreSql en fait un argument de portage depuis Oracle mais en pratique c'est du marketing car seule une infime partie des packages equivalents existent (solution PostGre qu'on a abandonné egalement).

[mattdef]

J'ai souvent eu à porter des procédures stockées et des fonctions d'Oracle vers SQL Server et comme je le disais, je n'ai jamais eu de gros souci avec ça.
Après je ne suis pas un expert Oracle et je n'ai peut être jamais eu à faire à des BDD complexes "progammaticalement" parlant.
Pour moi, une bonne BDD, c'est le strict minimum de logique métier, uniquement sur des points critiques en terme de performance. le reste doit être fait dans le programme.
Mais je me trompe peut-être...

[dfiad77pro]

Bonne chance pour automatiser cela si les procs oracles utilisent des Types Tableaux avec des %TYPE %ROW (les références sur un type n'existent pas à ma connaissance sur SQL_SERVER ).

En tout cas sur les bases complexes, c'est pas si évident, notamment si tu utilise l'EBR (Edition multiple). Et ensuite faut se méfier des différences de plan d'exécution/optimiseur ... Bref nous on a une base avec 700 000 lignes de PL/SQL multi-éditionné, 50 schémas...

En effet on a énormément de métier dedans, c'est un choix de conception (y'a des gens qui militent pour ) :

Pour moi, une bonne BDD, c'est le strict minimum de logique métier, uniquement sur des points critiques en terme de performance. le reste doit être fait dans le programme.

Dans un service à la rigeur??
Pour moi l'embarquer dans le programme n'est pas toujours une bonne idée sauf dans les cas suivants :
- Pas de besoin d'aller retour entre la base et le clients
- Algo style tableur ou il est nécessaire de calculer à chaque saisie ( pour ensuite pousser le résultat vers la base)
- Tout autre algos ne nécessitant pas de base ( compression vidéo, hors ligne etc..)

[frfancha]

Pour moi, une bonne BDD, c'est le strict minimum de logique métier

Oui, ben alors pas du tout justement. Tout doit être dans la DB, cela permet d'attaquer la même logique d'où que ce soit.
Et s'il y a bien un truc qui est pérenne dans le temps c'est bien SQL, alors les techniques qui construisent les couches auour changent tous les 3 ans

[kilroyFR]

Pendant des années on a tout codé au plus pres de la BDD (parce que ca a du sens de vouloir centraliser le metier en 1 seul endroit, tirer partie des capacités des BDDs, tirer partie des performances du serveur, mise en cache des requetes, securité au travers procedures stockées etc.).

Depuis ces dernieres années et avec le nombre grandissant de dev C# qui ne voient la BDD que comme du simple stockage (enfin tous les nouveaux rentrés chez nous en tout cas), la conception s'est transformée en 'on met toute l'intelligence/metier' hors de la BDD dans du C# parce que c'est mieux pour les tests unitaires (coder des tests unitaires en PL/SQL c'est pas sexy...).

Conclusion (les WS et autres passent leur temps a lire/ecrire des volumes de données considerables pour les stocker/mapper dans des objets C# (representation memoire a l'identique des tables) - ils en sont arrivés au point de selectionner des volumes et tout faire les tris/filtres etc. localement sur le client.
Bref le boulot et l'intelligence se retrouve deplaces dans une couche WS et ce que fait habituellement la BDD (cache, controle intégrité, tri etc) est réalisée dans le code C#...
Bref pour la plupart des anciens, c'est un non sens (d'ailleurs on le voit au niveau des perfs/charges reseau c'est catastrophique - merci SOA).
La BDD est presque du luxe a ce niveau; de simples fichiers a plats seraient suffisants.

Je suis totalement d'accord avec dfiad77pro. C'est en fonction de ce qu'on veut faire qu'on stocke le code a tel ou tel endroit mais pour moi des qu'il y a du volume on laisse la BDD le faire localement (ca evite les A/R inutiles et couteux) et on ne recupere que le resultat.
Visiblement la logique actuelle (surement avec les clients javascripts qui prennent enormement d'importance), on met tout dans le client. A une autre epoque (qui reviendra c'est cyclique) c'etait on met tout sur le serveur.

D'ailleurs sur la remarque de l'interlocuteur precedent c'est tout a fait ce qu'on a vecu. Sur un gros projet nous avions un intégriste/gourou WPF/SL qui nous a vendu sa sauce comme jamais (une conception rigoureuse, l'etat de l'art au point ou il repassait derriere tout le monde pour refactorer le code...). Bref au bout de 6 ans et des platres essuyés en grande quantité, la techno retenue etant jugée obsolete sur nos nouveaux projets et de passer a des technos clients legers html5.
Quelle partie a pu etre recupérée telle qu'elle ? la BDD SQL + DAL. Quelle partie a du etre refaite entierement ? l'intelligence mise dans couche metier/ WS et les IHM => poubelle.

Donc effectivement depuis nous avons une vision bien differente de toutes nouvelles technos revolutionnaires qui au final ne font rien de mieux que les autres.

[mattdef]

Je ne suis pas d'accord. Je sais d'expérience que l'on attaque jamais la même logique justement. Ou alors c'est un besoin très rare.

Dans quel cas avez-vous besoin que plusieurs applications différentes utilisent la même logique d'une BDD ?

[kilroyFR]

Une requete SQL (CRUD) vers une BDD est l'equivalent d'une requete (WS) qu'on ferait vers un serveur web pour MAJ/inserer/supprimer/recuperer des données.
(On est juste une couche au dessus dans le cas des WS alors que la couche metier est plutot tres proche voir fusionnée avec le moteur BDD. Donc fondamentalement rien de revolutionnaire dans les WS).

quand tu codes un WS il fournit un service qui potentiellement peut etre utilisé a l'identique par beaucoup d'autres consommateurs (SOA).
Avec la BDD ca n'est pas different; juste pas les memes technos employées.

[martopioche]

Depuis ces dernieres années et avec le nombre grandissant de dev C# qui ne voient la BDD que comme du simple stockage (enfin tous les nouveaux rentrés chez nous en tout cas), la conception s'est transformée en 'on met toute l'intelligence/metier' hors de la BDD dans du C# parce que c'est mieux pour les tests unitaires (coder des tests unitaires en PL/SQL c'est pas sexy...).

Conclusion (les WS et autres passent leur temps a lire/ecrire des volumes de données considerables pour les stocker/mapper dans des objets C# (representation memoire a l'identique des tables) - ils en sont arrivés au point de selectionner des volumes et tout faire les tris/filtres etc. localement sur le client.
Bref le boulot et l'intelligence se retrouve deplaces dans une couche WS et ce que fait habituellement la BDD (cache, controle intégrité, tri etc) est réalisée dans le code C#...
Bref pour la plupart des anciens, c'est un non sens (d'ailleurs on le voit au niveau des perfs/charges reseau c'est catastrophique - merci SOA).
La BDD est presque du luxe a ce niveau; de simples fichiers a plats seraient suffisants.

ça y est, ça aussi fallait le copier de Java ? Oh désolé, mais en effet, ça fait plus de 10 ans que j'avais commencé à le voir là bas… Je dirai quand même que c'est révélateur d'une organisation où on se dit qu'un dev remplace un expert données/DBA, mais comme il ne connait rien aux bases de données, tout se fait dans le code…

Je ne suis pas d'accord. Je sais d'expérience que l'on attaque jamais la même logique justement. Ou alors c'est un besoin très rare.

Dans quel cas avez-vous besoin que plusieurs applications différentes utilisent la même logique d'une BDD ?

La première aberration que j'ai vu… En fait, non, la formulation exacte est "l'aberration que l'on voit en permanence" est l'absence d'une notion de base comme l'intégrité référentielle (les clauses ON DELETE par exemple). Ces directives doivent être dans la base car elles sont garantes de la cohérence des données.

On n'attaque peut être pas la même logique entre applis, mais les règles métier ne changent pas. Les cas où on a besoin d'utiliser la même logique, c'est lorsqu'on a des règles métier et des données structurées. Quand on ne sait pas ce que l'on fait et que les données sont sans importance, là…

[kilroyFR]

Dans le genre de derive entre des devs orientés BDD et les autres, le cas du JSON. Dans le genre des dernieres demandes : passer a MongoDb car 'on n'a pas a s'emmerder a definir des structures fixes et en plus on stocke le json tel quel depuis le C#; y a rien a faire'...
Voila le genre de comportements qu'on doit subir ces dernieres années.

2 façons de voir le monde... (la verité c'est qu'en prod ils galerent - alors les pbs ne sont jamais dans le code mais dans la BDD (Oracle c'est de la merde, il faut mongo db ou hadoop), l'infra est pourrie (reseau GB pas suffisant), machines savec peu de RAM (16Go de RAM tu fais rien etc....).
C'est malheureusement cette seconde ecole qui, ramenant avec elle tout un vocabulaire 'sexy' pour des managers, a le vent en poupe. Si c'est pas malheureux...

[dfiad77pro]

Y'a aussi un peu les temps de dev ridicule qu'on nous alloue parfois :


Par exemple coté .NET , coder une requête complexe avec Entity Framework est beaucoup plus rapide que de :

- Créer les types complexe oracles/sql server et la procédure stockée
- Effectuer le binding manuel coté C# sur les types complexes (non géré en scaffolding) dans le service ou l'application


Par contre :
- Les performances ne sont pas toujours au rendez-vous ( perso je suis dans une grosse boite et je doit tout me taper, le front, le back...)
- Si vous devez taper dans plusieurs schéma c'est mort ( on maitrise moins les requêtes inter schéma)
- Type complexe (tableaux UDT) en entré + provider oracle managé = incompatible.


Deux trucs que j'aime pas trop dans le PL/SQL :
- on se retrouve vite avec des packages très volumineux genre 5000 lignes de code la ou les normes java /C# demandent de séparer en classe de 1000 lignes grands max.
- chaque boites à ses propres normes (comme tout les langages, mais c'est encore plus poussé je trouve)

[crevecoeurj]

Développer en objet poussent à développer la partie métier sur la couche client car "normalement ", on peut attaquer différentes Bases de données.

Intéressant selon la nature des projets bien sur.

[kilroyFR]

Deux trucs que j'aime pas trop dans le PL/SQL :
- on se retrouve vite avec des packages très volumineux genre 5000 lignes de code la ou les normes java /C# demandent de séparer en classe de 1000 lignes grands max.
- chaque boites à ses propres normes (comme tout les langages, mais c'est encore plus poussé je trouve)

1/ C'est comme avec la plupart des langages c'est au dev de respecter les bonnes pratiques et donc decouper de maniere a avoir des blocs de code le moins volumineux possible.
D'ailleurs venant d'ADA PL/SQL est au contraire un langage qui impose de base une gestion des exceptions là ou souvent des devs C# s'en passent allegrement (et se contentent du "vomi" d'exception pour comprendre les bugs).

2/ normes de codage c'est souvent fortement inspiré des regles de codage du fournisseur du langage (avec d'eventuelles adaptations; genre prefixer les noms de variables etc en fonction des regles dans l'entreprise).

[SQLpro]

Bonne chance pour automatiser cela si les procs oracles utilisent des Types Tableaux avec des %TYPE %ROW (les références sur un type n'existent pas à ma connaissance sur SQL_SERVER ).

Ben si, cela s’appelle généralement un domaine SQL et fait partie de la norme. Sur ce point Oracle n'a jamais été bon. Sous SQL Server il suffit d'utiliser les TYPE. Pour les tableaux il y a les variables table...

A +

[SQLpro]

Oui, ben alors pas du tout justement. Tout doit être dans la DB, cela permet d'attaquer la même logique d'où que ce soit.
Et s'il y a bien un truc qui est pérenne dans le temps c'est bien SQL, alors les techniques qui construisent les couches auour changent tous les 3 ans

Je te rejoins haut la main....

En 35 ans, j'ai vu les applications passées de COBOL à Pascal puis à C, puis à C++, puis à Delphi puis à Java, puis a C#, puis à PHP, puis à Python... Mais j'ai rien vu d'autre côté SGBDR que SQL...

A +

[SQLpro]

Sur un gros projet nous avions un intégriste/gourou WPF/SL qui nous a vendu sa sauce comme jamais (une conception rigoureuse, l'etat de l'art au point ou il repassait derriere tout le monde pour refactorer le code...). Bref au bout de 6 ans et des platres essuyés en grande quantité, la techno retenue etant jugée obsolete sur nos nouveaux projets et de passer a des technos clients legers html5.
Quelle partie a pu etre recupérée telle qu'elle ? la BDD SQL + DAL. Quelle partie a du etre refaite entierement ? l'intelligence mise dans couche metier/ WS et les IHM => poubelle.

Pour info nous avons eu la même chose chez un grand de l'assurance... Arrivée d'un nouveau DSI pour la refonte de la plateforme de gestion des contrats. Intégriste de l'ORM et donc mise en place d'Hibernate...
En tant qu'experts SQL nous lui avons indiqué à mainte reprise qu'il faisait fausse route et qu'il allait tout planter. Bref après trois ans de redéveloppement, la mise en prod a été catastrophique... Les temps de réponse monstrueux et les utilisateurs dégoutés... Qu'a t-il fait ? Mise en cause de SQL Server... c'est de la m... ça verrouille... à l'entendre il fallait prendre MySQmerde, etc.
Qu'as t-on fait : intervention en urgence à raison d'un jour par semaine à 1 600 € HT pour identifier et résoudre les problèmes...
Mais pour lui faire comprendre, les factures mentionnaient systématiquement "Résolution des problèmes de performances liés à l'utilisation d'Hibernate".
Trois ans après il a été viré avec pertes et fracas !
En effet, le budget "réparation" de ses erreurs a été audité par les contrôleurs de gestion qui se sont demandé qu'est-ce que c'était que de Hibernate... Et comme c'est lui qui avait imposer cette merde, c'est lui qui a dégagé !

A +

[SQLpro]

Je ne suis pas d'accord. Je sais d'expérience que l'on attaque jamais la même logique justement. Ou alors c'est un besoin très rare.

Dans quel cas avez-vous besoin que plusieurs applications différentes utilisent la même logique d'une BDD ?

Attendez d'avoir un peu d'expérience et on en reparlera....

A +

[SQLpro]

Tout est dans le titre !

http://fil.cigref.fr/_upload/documen...cle2017-Fr.pdf

A +