Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Michael Guilloux

95PARTAGES

9  0 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de ManyTwo
Membre du Club https://www.developpez.com
Le 11/10/2017 à 11:00
La je vois surtout des sysdba qui défendent leur bout de gras.
Même niveau que des pro "tout logiciel".

Dire que mettre la logique métier dans la base est une règle fondamentalement meilleure est un non sens, tout comme dire l'inverse.
Il y a du pour est contre des deux cotés, suivant les projets on va privilégier différentes choses...

Déjà suivant le moteur de base de données, cela peut complètement changer la donne.

Dans mon entreprise actuelle (15aine d'employés), historiquement la logique métier est en BDD (interbase).
Le logiciel principal un ERP spécialisé, gérant des fonctionnements métiers complexes.

Et bien cela commence à poser de sérieux soucis.

De fiabilité du code:
Aucun test automatisé (donc aucune répétition en cas de changement), faire des tests unitaires sur des BDD reste plus compliqué à faire (aucun outil pour Interbase en tout cas).

De performance:
Pourtant à première vue les SGBDR sont optimisés et performants, mettre du code dedans est une bonne idée. Mais ne pas décharger une partie de la logique en amont peut nuire aux performances.
Quand pour des calculs pour arriver à un état final oblige à beaucoup de mises à jour de tables, pour relancer des triggers qui calculent, réécrire n fois les mêmes valeurs et bien on arrive à surcharger la base. Même si les SGBDR optimisent l'I/O et l'accès mémoire.

De scalabilité:
si besoin de répliquer le code métier, notamment la puissance de calcul, pas le choix: il faut faire du load balancing sur la base. Donc réplication. Donc compliqué, surtout lorsque qu'arrive les mises à jours du code métier.

De limitation de code:
Les SGBDR ne sont pas prévus à la base pour la même chose que les language de développement.
C'est complémentaire et non en compétition, comme vous voulez le faire croire. Comment tu gères le mutli threading dans ton code pour faire du calcul parallèle? Peut être qu'oracle a des solutions, la plupart des SGBDR, ou des gens qui font du SQL coderont en procédural mono thread.

Alors bien sur il y a des solutions pour limiter chaque impacte j'imagine, encore faut t'il y avoir des experts BDD qui ont le temps de se pencher sur l'optimisation des procédures de chaque dev etc.

Ici je met en avant certaines contraintes qui nous posent problème, mais il y a beaucoup de points positifs pas de soucis la dessus. Le but est de démontrer qu'il n'y a pas de règle universelle, et surtout qu'il faut arrêter de voir le code BDD et le code logiciel comme des concurrents.

Le but est de trouver un équilibre, qui satisfera les critères importants du projet (pas des équipes, du projet en général hein^^).
La performance? Maintenabilité? scalabilité? Compétences en interne et sur le marché (souvent négligé...)? Fiabilité et intégrité des données (le NoSql montre bien que certains projets ne necessistes pas une intégrité forte)?

[troll /on],Finalement le discours des "pro DB" est aussi limité que celui des "pro logiciel": "C'est mon coté qui est mieux d'abord"! [troll /off]
3  0 
Avatar de frfancha
Membre éclairé https://www.developpez.com
Le 10/10/2017 à 21:19
Citation Envoyé par mattdef Voir le message

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
3  1 
Avatar de kilroyFR
Membre éclairé https://www.developpez.com
Le 10/10/2017 à 22:00
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.
2  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 11/10/2017 à 9:52
Citation Envoyé par frfancha Voir le message
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 +
2  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 11/10/2017 à 10:01
Citation Envoyé par kilroyFR Voir le message
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 +
2  0 
Avatar de kilroyFR
Membre éclairé https://www.developpez.com
Le 10/10/2017 à 18:01
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).
1  0 
Avatar de mattdef
Membre actif https://www.developpez.com
Le 10/10/2017 à 18:22
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à
1  0 
Avatar de mattdef
Membre actif https://www.developpez.com
Le 10/10/2017 à 19:59
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...
1  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 10/10/2017 à 20:39
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..)
1  0 
Avatar de kilroyFR
Membre éclairé https://www.developpez.com
Le 10/10/2017 à 22:18
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.
1  0