Discussion :

[SQLpro]

Je reste sceptique sur cette affirmation, j'aurais tendance à penser que MySQL est loin devant (je serais curieux de savoir combien Facebook fait tourner d'instances MySQL à un instant T).
Après ça dépend de quoi on parle, mais au final c'est SQLite qui surpasse tous les autres, y a sans doute pas un seul PC au monde qui n'ait pas au moins un SQLite.

Il vous suffit de lire les études que j'ai cité et vous verrez que MySQSL est pas mal positionné mais loin derrière Oracle et SQL Server. Attention, il s'agit d'études faites en entreprise et non auprès de quelques développeurs boutonneux !

1 - étude UNISPHERE 2015 :


2 - étude Information Week 2014 "State of Database technology" :


En gros, un peu mois de 2 à 3 fois moins de MySQL que d'Oracle et 2 à 4 fois moins qu'avec SQL Server selon les différentes études....
Quand à SQL Lite, trop marginal pour être cité !

A +

[SQLpro]

Bonne nouvelle pour les utilisateurs de SGBD.

Dans ce cas là pourquoi MySQL a réussi à faire sa place bien qu'il soit gratuit comme PostgreSQL ?

MySQL n'est pas gratuit... Vous payez soit en offrant votre code, soit en monnaie sonnante et trébuchante. La paiement d'un bien n'est pas forcément en monnaie. Cette forme de paiement est d'ailleurs bien connue en immobilier ou dans les œuvres d'art (paiement dation).

la popularité de MySQL tient d'abord au fait que c'est une entreprise contrairement à PostGreSQL. Dans une entreprise sil y a des commerciaux dont le métier et de fourguer la camelote. L'entreprise originelle s’appelle MySQL AB (puis Sun, puis oracle) et elle a fait du lobbying auprès des hébergeur et des fournisseurs de solutions Linux packagées pour que l'on trouve MySQL dans le paquet cadeau... Et les développeurs irréfléchis se sont précipité dessus par fainéantise !

PostgeSQL n'a pas d'entreprise au cul pour booster ses ventes et la solution n'en a encore plus de mérite !

A +

[SQLpro]

... j'en suis venue a prendre PGSQL car Fiable avec un respect des normalisations

Héls de moins en moins vrai au fil du temps....

Quelques exemples de la norme SQL qui n'ont pas été implémenté ou pire avec des solutions autres :

• MERGE non implémenté
• Temporal table pas de solution (les tentatives de montrer quelques choses de similaire font doucement rigoler)
• FULL OUTER JOIN incomplet

A +

[SQLpro]

Ce n'est pas tout à fait ce qui est dit... la question est "What database brands do you have running in your organization". Donc une boite qui a surtout du Oracle et un peu de SQL Server va aussi répondre SQL Server. Ca ne veut pas dire que 87.37 % des entreprises sont principalement sous SQL Server, juste que c'est un des SGBD qu'elles utilisent.

Cela étant dit, j'avoue que les chiffres présentés dans l'article me semblent assez surprenants... je pense que d'autres études donneraient des chiffres nettement moins favorables à SQL Server.

Pour avoir discuté depuis quelques temps de ces chiffres avec des experts mondiaux sur le sujet et suivre ces chiffres depuis plus de 5 ans, ce que je peut vous dire c'est que la situation en France n'est pas du tout celle de l’internationale.

Aux USA l'abandon d'Oracle est tellement réel qu'Oracle aux abois fait de la pub partout pour tenter de retrouver des clients notamment dans le Wall Street Journal tous les jours en une, et dans les aéroports...


En France on est resté très oraclien à cause des grosses société hérités de l'état EDF, SNCF, Air France... dont les fonctionnaires trainent des pieds au changement...
Un gros éditeur Anglais très implanté en Europe et aux USA m'a indiqué que leurs solutions qui auparavant était disponible sous Oracle et SQL Server, ne serait bientôt plus disponible sous Oracle. Mais les chiffres sont très intéressants : aux USA moins de 2% d'Oracle; En France encore 30% d'Oracle ! Difficile d'annoncer officiellement cela, aux clients français !!! Mais plus aucun investissements n'est fait par cet éditeur, présent dans plus de 15 % des entreprises françaises, sur la plateforme Oracle.... Même certains module ne sont plus disponibles que sous SQL Server obligeant les clients français à faire cohabiter du oracle et du SQL Server (sans que d'ailleurs certaines s'en aperçoivent !)

En Allemagne la pénétration de PostGreSQL est bien plus forte que celle de mySQL. Structure d'entreprise oblige. MySQL ne supporte que les petites charges.. et encore à plus de 100 utilisateurs il se vautre. Or en Allemagne le tissus entrepreneuriale est fait de beaucoup d'entreprises de taille moyenne... Rien à voir avec la France faite de TPE !

A +

[Stéphane le calme]

Data Driven : Microsoft annonce la disponibilité de la préversion privée de SQL Server 2016 sur Linux
et propose des licences gratuites aux DBA Oracle

Durant la conférence Data Driven, Microsoft a fait le point sur les fonctionnalités proposées par SQL Server 2016, mais s'est également lancé à l'assaut d'Oracle.

Dans son offre de migration, Microsoft propose des licences gratuites SQL Server (toutefois, une souscription à l'assurance logicielle est requise) des formations gratuites SQL Server Essentials pour les administrateurs de bases de données Oracle (cette offre est disponible jusqu'au 30 juin 2016) ainsi que des subventions de déploiement de service pour démarrer les migrations (une offre qui est également disponible jusqu'au 30 juin 2016).

C'est d'ailleurs ce que Judson Althoff, President of Microsoft North America Sales & Marketing, a expliqué en faisant une comparaison détaillée entre SQL Server 2016 et Oracle dans un scénario faisant appel à différentes fonctionnalités embarquées dans SQL Server 2016. Quand les fonctionnalités embarquées dans SQL Server 2016 étaient comparées à celles proposées par les produits Oracle, il a avancé « qu'Oracle est pratiquement douze fois plus cher ».

« Aussi, si vous voulez effectuer la migration depuis Oracle, nous vous octroierons des licences gratuites SQL Server », a-t-il assuré dans sa présentation. « Pour toute instance Oracle que vous avez, vous obtiendrez des licences gratuites SQL Server. Tout ce que vous avez à faire est de posséder un accord Software Assurance avec Microsoft. Si vous souhaitez entreprendre ce voyage avec nous avant la fin du mois de juin, nous allons vous aider et investir dans les coûts de migration, mettre des ingénieurs sur le coup pour vous aider à effectuer la migration depuis Oracle ».

Mais qui peut en bénéficier ? « Tout le monde est éligible », a précisé Althoff.

Microsoft a également attaqué Oracle au niveau de la sécurité, se référant aux informations publiées par le National Institute of Standards and Technology qui a publié une liste de bases de données et les vulnérabilités associées. Joseph Sirosh, corporate vice president of the Data Group de Microsoft, a rappelé dans sa présentation qu'en moyenne, sur les années précédentes, SQL Server avait le dixième (1/10) des vulnérabilités découvertes sur Oracle.

Il a également mis en exergue de nouvelles fonctionnalités de sécurité embarquées dans SQL Server : « dans SQL Server 2016, pour la première fois, vous entendrez parler d'une fonctionnalité que nous avons appelée Always Encrypted ». « Il s'agit ici de sécuriser les données tout le long du chemin, depuis le client jusqu'à la base de données, et de les garder sécurisées même quand le processus de requêtes est achevé. Sur la base de données du site, les données ne sont jamais déchiffrées, même dans la mémoire, et vous pouvez encore effectuer des requêtes dessus ».

Lorsque Scott Guthrie, Executive Vice President du Cloud and Enterprise Group, a pris la parole, il a annoncé que la préversion privée de SQL Server sur Linux est désormais disponible. Il a expliqué que cette décision faisait partie d'une stratégie de l'entreprise consistant à apporter ses produits et services à un éventail plus large d'utilisateurs, mais aussi pour « rencontrer les clients où ils sont ».

« Nous avons conçu SQL Server 2016 pour aider les entreprises à anticiper les perturbations d'aujourd'hui. Il prend en charge le traitement hybride transactionnel/analytique, les analyses avancées et le machine learning, la BI mobile, l'intégration des données et offre la possibilité de chiffrer en permanence les requêtes » a expliqué Guthrie. « Il s'agit même là peut-être de la première base de données relationnelle au monde qui soit « née du Cloud-first », avec la majorité des fonctionnalités qui ont d'abord été déployées et testées sur Azure, dans 22 centres de données dans le monde et des milliards de requêtes par jour. Il a été testé par la clientèle et est prêt pour la bataille », a-t-il continué.

Source : Data Driven (Microsoft), blog Microsoft, document relatif à l'offre de migration (au format PDF)

[redcurve]

Les bases de données SQL server arrivent bien en tête du nombre de serveurs installés.

Mais les résultats changent totalement si on prend en compte les terra (data) de données gérées. Dans ce domaine, les bases Mysql ont un fort leadership, avec l'utilisateur Google.

Enfin, toujours chez Google, remarquons que Nosql et MongoDB font une belle percée !!!

Petite info venant de chez Google heu comment dire ils n'utilisent plus du tout MySQL sauf pour les applications où ils peuvent se permettre de perdre des données (MySQL n'est pas fiable mais suffisant pour ce genre d'appi, Facebook fait pareil ). En réalité ils utilisaient surtout l'interpréteur SQL, qui a été branché au dessus de F1. MySQL en lui même n'a que peu d'intérêt, le moteur de stockage par défaut n'est rien d'autre que BerkeleyDB qu'ils ont trouvé le moyen de rendre moins fiable ... Des génies chez MysqlAB/Oracle

[Invité]

Bien que cela soit un défi technique, 98% de supercalculateurs et 90% de serveurs GNU/Linux avec 88% de Microsoft SQL Server donne une stratégie financière satisfaisante pour toutes les parties (fournisseurs, clients, utilisateurs, actionnaires, administrateurs, développeurs,... ).

Tomahawk enterré. Retournons fumer le calumet de la paix.

[kilroyFR]

Le pb de SQL Server c'est que ce qui fait la force d'Oracle c'est a dire son langage procedural PL/SQL. Dans ma boite on utilise massivement ce langage et donc on est et on restera fortement lié a Oracle meme si sql server devenait gratuit. Reecrire des milliers de lignes en PL/SQL vers TSQL est inimaginable.

A un moment on avait envisagé passé a Postgresql qui a une certaine compatibilité avec Oracle PL/SQL mais ca a ete abandonné egalement (trop de code a porter).
De plus Oracle nous permet jusqu'a maintenant de ne pas se soucier de la plateforme cible (linux/windows etc) en fonction de la demande du client sans qu'on ait a s'en soucier. Donc pour les grosses applis existantes je vois mal comment SQL Server pourrait s'imposer.

[SQLpro]

....Donc pour les grosses applis existantes je vois mal comment SQL Server pourrait s'imposer.

ça fait longtemps que les grosses applis existantes migrent massivement sous SQL Server...
Exemple : SAP offre une version SQL Server depuis 2005 et s'en trouve plus économique plus performant et moins couteux...
http://download.microsoft.com/downlo...howcase_fr.pdf

A +

[sevyc64]

Le pb de SQL Server c'est que ce qui fait la force d'Oracle c'est a dire son langage procedural PL/SQL. Dans ma boite on utilise massivement ce langage et donc on est et on restera fortement lié a Oracle meme si sql server devenait gratuit. Reecrire des milliers de lignes en PL/SQL vers TSQL est inimaginable.

Inimaginable, non.
Long sans doute, couteux en temps et en travail, oui. Mais il y a bien d'autres projets, certainement plus couteux, qui se réalisent pourtant.

Comme je dis souvent, dans ce genre de projet, ce qui est le plus souvent très long et très couteux, c'est de se décider à lancer sérieusement l'étude de la faisabilité tant économique que technique du potentiel futur projet.
Tout est question de décision à prendre et à assumer. C'est généralement là le plus gros frein.

De plus Oracle nous permet jusqu'a maintenant de ne pas se soucier de la plateforme cible (linux/windows etc) en fonction de la demande du client sans qu'on ait a s'en soucier.

Ben justement c'est ce que va te permettre aussi SQL Server maintenant aussi.

Donc pour les grosses applis existantes je vois mal comment SQL Server pourrait s'imposer.

Il y a bien longtemps que SQL Server absorbe sans problème les très grosses bases à l'image d'Oracle.
Des bases dépassant les To, montées en cluster, n'est pas une situation tant anecdotique que ça.

[kilroyFR]

"Long sans doute, couteux en temps et en travail, oui."
=> Quand je dis inimaginable, c'est irrealiste - on n'est plus dans un mode ou on change de techno pour le plaisir de quelques developpeurs. L'investissement en temps etc est trop important et peu envisageable dans un environnement ou on cherche a baisser les couts de devpts. Refaire pour refaire et se retrouver fonctionnellement avec la meme chose ca n'a aucun interet (le client achete un fonctionnel, pas une techno, il se fout que ce soit Oracle/sql server ou autre - une BDD reste une BDD).

Les etudes de faisaibilité/couts ont les a vite faites. Oui Oracle peut etre lourd quelques fois mais on ne paie jamais les prix publics (c'est comme pour les prix des voitures neuves).
En tant que fournisseur de logiciel cle en main (le client ne touche pas a la BDD qui fait partie du logiciel livré) on a >80% de reduction donc ca a toujours rendu inutile le passage sous SqlServer.
Si c'est pour changer de solution, autant alors passer a une solution non proprietaire et essayer de recuperer tout ce qui a ete codé/testé etc.; mais passer de l'un a l'autre je n'y vois pas bien l'interet (a part s'enfermer encore un peu plus dans les specificités de l'un et de l'autre).
Pour les grosses applis Oracle l'alternative qui tient a la route en ce moment c'est PostGreSql (recuperation d'une partie du code PL/SQL); impossible de faire comprendre a un commercial que de passer de Oracle a SqlServer va lui faire gagner de l'argent (en tout cas dans ma boite ca ne se passe pas - fonctionnellement ca fait toujours la meme chose - pourquoi aller claquer des centaines d'heures de portage pour faire la meme chose ?). Les gains de licences "gratuites" sont un leurre et en concerneront certainement que les versions basiques (genre sqlserver express donc aucun interet).
Je n'ai jamais dit que sqlserver ne savait pas gerer de grosses BDD; il sait faire ... comme les autres.

Microsoft et sa strategie a geometrie variable et ses errements quel que soit le sujet technique (maintenant ils s'interessent a Linux mais rien ne dit qu'ils ne laisseront pas tomber dans quelques mois pour je ne sais quelle nouvelle raison sortie du chapeau).
Plus aucun confiance depuis qu'ils nous ont planté avec silverlight//wpf (enfin chez nous ca a couté enormement en investissement pour tout jeter et refaire a la sauce client leger - merci M$). Oracle c'est un peu plus cher mais ca rassure aussi les clients.
Et parler de SAP/Oracle, normal que ca ne colle pas ils sont en procés depuis des années.

[SQLpro]

Votre commentaire est un tissus de bétises !

"Long sans doute, couteux en temps et en travail, oui."
=> Quand je dis inimaginable, c'est irrealiste - on n'est plus dans un mode ou on change de techno pour le plaisir de quelques developpeurs. L'investissement en temps etc est trop important et peu envisageable dans un environnement ou on cherche a baisser les couts de devpts.

Sauf que ne serait-ce que 10% de moins en licences pour un éditeur qui peut avoir plusieurs dizaines milliers de clients ça finit par couvrir plus que largement les frais de redéveloppement et permet de mieux vendre sa solution.
Au liue de vous repliez sur votre petite expérience personnelle étriquée dans votre boite, ouvrez les yeux sur d'autres entreprises et vous verrez que beaucoup d'entre elle font le grand saut et je suis sûr qu'avant 2 ans, ce sera de même dans votre entreprise... Nus en reparlerons !

Refaire pour refaire et se retrouver fonctionnellement avec la meme chose ca n'a aucun interet (le client achete un fonctionnel, pas une techno, il se fout que ce soit Oracle/sql server ou autre - une BDD reste une BDD).

Pas si vrai que cela... Les fonctionnalités sont pas les mêmes et les couts pas du tout. Par exemple Oracle a été en retard sur le In Memory et est totalement absent du cloud... Et ça, sa pardonne pas. Quelques uns de mes nouveaux clients quittent Oracle pour aller vers du SQL Server en refonte d'appli à cause du cloud.

Les etudes de faisaibilité/couts ont les a vite faites. Oui Oracle peut etre lourd quelques fois mais on ne paie jamais les prix publics (c'est comme pour les prix des voitures neuves).

L'écart est juste de plus de 10 fois
Pièce jointe 203914
Et les remises Oracle dépassent rarement 70% et 40 % chez Microsoft. La différence est donc très avantageuses pour SQL Server. Tous les experts Oracle le savent qui voient des clients hurler et se tourner vers du "tout sauf oracle".
Exemple, il y a 8 ans, la BI d'un gros avionneur américain à migré d'Oracle à SQL Server (plusieurs centaines de To sur 120 serveurs : une dizaines de DataWarehouse + 100 serveurs de reporting en ferme + ...). Bilan, plusieurs centaines de millions de dollars de licences Oracle économisé !

En tant que fournisseur de logiciel cle en main (le client ne touche pas a la BDD qui fait partie du logiciel livré) on a >80% de reduction donc ca a toujours rendu inutile le passage sous SqlServer.

La encore une différence fondamentale... Avec les contrats d'éditeurs logiciels Microsoft sur SQL Server c'est pas 80% de réduction, c'est 0 €, nada.. rien à payer et en plus la version Enterprise !

Si c'est pour changer de solution, autant alors passer a une solution non proprietaire et essayer de recuperer tout ce qui a ete codé/testé etc.;

Compte tenu du nombre de bugs de MySQmerde et ses performances lamentable lors de la montée en charge... c'est même pas la peine d'essayer... Pour PostGreSQL c'est bien gentil, mais les principaux éléments qui pourrait en faire quelques chose d'utile, n'y sont pas :

• pas de parallélisme des requêtes ni de lecture écriture des disques
• un seul journal de transaction pour toutes les bases (point de contention catastrophique)
• pas de pilotage des transactions dans les routines
• pas de partitionnement
• pas de DDL online
• pas de transaction sur DDL / DCL
• pas de vues indexées
• pas d'index INCLUDE
• pas d'index verticaux,
• pas de "in memory"
• un optimiseur plus que pauvre (au delà de 12 jointures il se vautre à cause de GEQO et si l'on pousse le paramétrage au dessus, genre 20 jointures, il passe plus de temps à trouver un plan à peine acceptable qu'à l'exécuter !)
• et pour couronner le tout un VACUUM (nécessaire du fait du MVCC qui farcie les pages de ghost records) et malheureusement pourri la base d'un maximum de deadlock, obligeant à interdire les accès au serveur pendant la maintenance !

mais passer de l'un a l'autre je n'y vois pas bien l'interet (a part s'enfermer encore un peu plus dans les specificités de l'un et de l'autre).

Commencez par les connaître ces spécificités ! On en reparlera.... D'autant plus que le SQL de SQL Server est l'un des plus proche de la norme, devant celui de PG maintenant, alors que le SQL d'Oracle a toujours été hyper spécifique et peu portable et ce n'est que très récemment qu'Oracle à enfin daigné, hélas un peu tard, à rejoindre la norme SQL.. Quelque petits exemples :

• les jointures externe (+)
• la récursivité limitée avec CONNECT BY PRIOR...
• l'adoption tardive des CTE
• NVL, DECODE, TO_CHAR/DATE... alors que la norme c'est COALESCE, CASE, CAST..

etc !

Pour les grosses applis Oracle l'alternative qui tient a la route en ce moment c'est PostGreSql (recuperation d'une partie du code PL/SQL);

Visiblement vous avez pas dû tester beaucoup la chose parce que ça marche jamais !

Rectification... Ha mais si !!!! Je vous cite :

A un moment on avait envisagé passé a Postgresql qui a une certaine compatibilité avec Oracle PL/SQL mais ca a ete abandonné egalement (trop de code a porter).

Donc, là vous êtes de mauvaise fois... dans un post vous dites noir et celui d'après vous dites blanc... Vous êtes mâle ou femelle ?

impossible de faire comprendre a un commercial que de passer de Oracle a SqlServer va lui faire gagner de l'argent (en tout cas dans ma boite ca ne se passe pas - fonctionnellement ca fait toujours la meme chose - pourquoi aller claquer des centaines d'heures de portage pour faire la meme chose ?).

Pourtant ce que font la plupart des boîtes aujourd'hui... Bref selon vous les autres seraient-ils des imbéciles ?

Les gains de licences "gratuites" sont un leurre et en concerneront certainement que les versions basiques (genre sqlserver express donc aucun interet).

Quand je disait que vous disiez de grosses conneries, ben en voila une comaque ! Relisez, c'est bien la version Enterprise qui sera gratuite à condition de faire du portage depuis un autre SGBDR. Il y a longtemps que la version Express est gratuite. Elle l'a toujours été !

Je n'ai jamais dit que sqlserver ne savait pas gerer de grosses BDD; il sait faire ... comme les autres.
Microsoft et sa strategie a geometrie variable et ses errements quel que soit le sujet technique (maintenant ils s'interessent a Linux mais rien ne dit qu'ils ne laisseront pas tomber dans quelques mois pour je ne sais quelle nouvelle raison sortie du chapeau).

Ha on y est... Vous avez un mal vécu avec MS, donc pour vous tout ce qui touche à MS c'est de la merde... N'auriez vous par par hasard un léger à priori ???

Plus aucun confiance depuis qu'ils nous ont planté avec silverlight//wpf (enfin chez nous ca a couté enormement en investissement pour tout jeter et refaire a la sauce client leger - merci M$). Oracle c'est un peu plus cher mais ca rassure aussi les clients.

Le un peu, c'est juste 10 fois dans la pratique.... Quand à Oracle ils en ont planté aussi pas mal... La faille de sécurité majeure sur les mots de passe pour laquelle ils ont mis plus de 2 ans à corriger c'est c'était le top... De toutes façons les métriques du NIST sont claire, Oracle a 4 fois plus de failles de sécurité que SQL Server ! Et en plus ils mettent 6 fois plus de temps à corriger leurs bugs.. Si ça c'est pas prendre les clients pour de la merde... Alors quand à les rassurer, vous me faites grassement rigoler !

Et parler de SAP/Oracle, normal que ca ne colle pas ils sont en procés depuis des années.

La question serait plutôt... Avec qui ne sont-ils pas en procès....

Et puis tient tant qu'à faire, parlons étique...

• D'un côté Larry Ellison, milliardaire, PDG d'Oracle dilapide son argent en luxueuses courses de voiliers (1 quart de millions de dollars...) et passe son temps à faire chier les autorités en faisant voler son mig 29 malgré les interdictions (dangerosité + pollution)...
• De l'autre Bill Gates, PDG de Microsoft, qui avec sa fondation a dilapidé 44 milliards de dollars en œuvre de bienfaisance.....

Je ne sais pas pourquoi, mais j'aurais tendance à prix et fonctionnalité équivalente à aller donner mes sous à MS et pas à Oracle !

A +

[kilroyFR]

Je n'ai aucun a priori ni ne suis fanboy de personne - je laisse ca aux gamins qui resume la techno a des querelles de clochets - toutes nos applis front office sont en .net et cela fait 25 ans qu'on fait du VC/VS donc j'ai un peu de retour.
Votre avis vaut ce qu'il vaut, le mien aussi. On n'a pas de milliers de clients mais seulement des gros qui veulent un logiciel maintenu pendant 10 ans (et oui c'est ca l'industrie) donc on peut difficilement prendre le risque de tout jeter et migrer sur autre chose comme ça.
Payer quelques licences Oracle sur des projets a plusieurs dizaines de millions d'euros ca represente une goutte d'eau.
Accessoirement, je ne viens pas ici pour me faire insulter.
Paradoxalement vous me traitez d'anti MS (ce qui est faux) mais visiblement vu votre signature vous etes un evangeliste donc discussion impossible. Je n'ai aucun parti pris contrairement a vous qui denigrez tout ce qui n'est pas microsoft (auriez vous des interets financiers a leur faire la pub ?).

J'ai juste dit qu'on a ete echaudés sur pleins de technos MS donc on a tendance a essayer de faire comme tout le monde : prendre du libre de partout ou on peut (Postgresql peut etre un jour mais pas les budgets a ce jour pour ne serait ce qu'envisager un debut de migration - ca reste le plus proche d'Oracle malgré tout - c'est uniquement ce que j'ai dit) et ne pas se lancer a corps perdu a la moindre decision de Microsoft.
Oracle a ete notre choix du depart, peut etre pas le bon mais pas le pire non plus lorsque le choix a l'epoque de Sql server s'appelait sybase et etait condamné (d'accord en 10 ans MS a tout reecrit mais nos applis de 1990 sont toujours en PROD a ce jour dans le monde entier - personne d'autre ne pouvait le garantir a l'epoque (et pour le multi plateforme demandé par nos clients il n'y avait qu'Oracle)).

[StringBuilder]

Une anecdote à propos d'Oracle...

En tant que distributeur et intégrateur de solutions ERP, cette expérience concerne un gros industriel français. Projet de plusieurs millions d'euros. Comme dirait kilroyFR, la licence Oracle est "une paille" par rapport au coût en licences du progiciel et du paramétrage.

Ok.

Suite à différents problèmes de performances (vive Oracle et son optimiseur qui préfère faire des full scan plutôt qu'un index seek sur une clé unique), on fait intervenir un DBA.
Il estime que le serveur physique est trop juste, et propose de faire un test sur une ferme de serveurs de virtualisation.
Ok, on coupe le serveur. On bascule sur la ferme.
Il active un certain nombre de paramètres permettant de faire un audit convenable.
Ne remarque au final pas grand chose de spécial.

Sauf un léger détail : "ah ben oui ma pauvre Lucette, on est passé sur une machine physique à 128 cœurs (pourtant, seuls 4 sont accessibles par la VM) et on a dû activer des options de trace disponibles qu'avec le mode de licence le plus cher... et on peut pas faire machine arrière, une fois que c'est activé, même par erreur, on peut plus faire marche arrière".
=> Résultat, la facture en licences Oracle dépassait au final de 10 fois l'ensemble du prix du projet tout entier !

Résultat, obligé de faire une réinstallation complète et perdre 3 semaines de boulot car pas moyen de récupérer les backups effectués sur la nouvelle config.

Vive Oracle quoi...

[Invité]

Tiré de la conférence Data Driven SQL Event de Microsoft ( https://www.microsoft.com/en-us/serv...ta-driven.aspx ) :

[SQLpro]

Je n'ai aucun a priori ni ne suis fanboy de personne - je laisse ca aux gamins qui resume la techno a des querelles de clochets - toutes nos applis front office sont en .net et cela fait 25 ans qu'on fait du VC/VS donc j'ai un peu de retour.
Votre avis vaut ce qu'il vaut, le mien aussi. On n'a pas de milliers de clients mais seulement des gros qui veulent un logiciel maintenu pendant 10 ans (et oui c'est ca l'industrie) donc on peut difficilement prendre le risque de tout jeter et migrer sur autre chose comme ça.

La question imbécile que je vous pose est la suivante... Combien de fois avez vous dû migrer la base oracle de version chez vos clients et combien cela a t-il coûté en interruption de service ?
Pour information depuis la version 7 datant de 1998 de SQL Server, les migration se font par :

• simple détach/attch des fichiers de la base (100 millisecondes d'interruption) jusqu'à la version 2005.
• mirroring par basculement (aucune interruption de service) depuis la version 2005 jusqu'à la version 2014
• AlwaysOn par basculement (aucune interruption de service) depuis la version 2012 jusqu'à la version 2016

Combien dure une migration de base chez oracle ?
Parce que la seule méthode "rapide" (avant c'était pire : export DDL + injection des données DML) c'est de faire une sauvegarde, une restauration et passer une qualité invraisemblance de scripts de mise à jour....
Bref, souvent plusieurs heures d'arrêt, alors que sur SQL Server c'est entre 0 et 100 ms depusi 1998 (soit 18 ans...)

J'ai juste dit qu'on a ete echaudés sur pleins de technos MS donc on a tendance a essayer de faire comme tout le monde : prendre du libre de partout ou on peut (Postgresql peut etre un jour mais pas les budgets a ce jour pour ne serait ce qu'envisager un debut de migration - ca reste le plus proche d'Oracle malgré tout - c'est uniquement ce que j'ai dit) et ne pas se lancer a corps perdu a la moindre decision de Microsoft.

Donc le libre est plus stable plus pérenne pour vous...

Que dire alors de MongoDB qui en 6 ans a changé 3 fois ses structures de stockage obligeant 2 migrations successives avec import export à chaque fois ???

Oracle a ete notre choix du depart, peut etre pas le bon mais pas le pire non plus lorsque le choix a l'epoque de Sql server s'appelait sybase et etait condamné (d'accord en 10 ans MS a tout reecrit mais nos applis de 1990 sont toujours en PROD a ce jour dans le monde entier - personne d'autre ne pouvait le garantir a l'epoque (et pour le multi plateforme demandé par nos clients il n'y avait qu'Oracle)).

Il est probable que le choix qui a été fait il y a dix ans était tout à fait approprié... mais il faut savoir se remettre en cause.... Pour ne pas avoir sut s’adapter biens des dinosaures ont disparus ! Et je croit qu'oracle en est à ce stade....

Il sera intéressant de scruter ce que va faire l'éditeur de Redwood Shores dans les mois a venir pour éviter l'hémorragie de départ de ses clients.....

A +

[kilroyFR]

Sinon a part traiter les gens d'imbeciles, faire les questions/reponses et prendre les gens de haut

T-SQL (code non compilé au passage alors que ca l'est chez Oracle) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
use master 
go
create procedure dbo.test as
 
DECLARE @command as varchar(1000), @i int
SET @i = 0
WHILE @i < 5
BEGIN
Print 'I VALUE ' +CONVERT(varchar(20),@i)
EXEC(@command)
SET @i = @i + 1
END

ben ca fait vraiment pas rever, et ca me ramene a environ 25 ans en arriere.

Et ne nous en deplaise, la grande tendance des BDD actuellement (dans le big data notamment) c'est le nosql (ou comment reinventer les BDD fichiers sequentiels indexes).
Il ne se passe pas un mois sans que nos developpeurs c# insistent pour passer vers ces BDD, parce que c'est plus simple pour stocker/manipuler des objets JSON completement destructurés !
Pour avoir experimenté c'est pas rassurant je l'accorde (sql considéré trop "complexe" ... remplacé par une syntaxe encore plus barbare/non standard = incomprehensible) - Oracle essaie de s'accrocher comme il peut (pour suivre la mode et ne pas passer a coté de quelque chose mais sans grande conviction).

[sevyc64]

Et ne nous en deplaise, la grande tendance des BDD actuellement (dans le big data notamment) c'est le nosql (ou comment reinventer les BDD fichiers sequentiels indexes).
Il ne se passe pas un mois sans que nos developpeurs c# insistent pour passer vers ces BDD, parce que c'est plus simple pour stocker/manipuler des objets JSON completement destructurés !
Pour avoir experimenté c'est pas rassurant je l'accorde (sql considéré trop "complexe" ... remplacé par une syntaxe encore plus barbare/non standard = incomprehensible) - Oracle essaie de s'accrocher comme il peut (pour suivre la mode et ne pas passer a coté de quelque chose mais sans grande conviction).

La grande tendance, tu l'as dis.
NoSQL est à la mode. Tout le monde veut faire du NoSql à toutes les sauces parce que c'est le tip-top tendance du moment. Tu fais pas du NoSql dans les années 2010, tu n'a rien compris à la vie.

Sauf que NoSql est un magnifique miroir aux alouettes, beaucoup en reviennent.

NoSql n'est réellement adapté que dans une utilisation vraiment bien spécifique des données, ce que tout le monde nomme pompeusement, sans d'ailleurs toujours vraiment en comprendre le sens profond, le "big-data".
Mais le big-data, n'en déplaise aux partisans, ne représente qu'une faible part d'utilisation de données mais spectaculaire car visible.
Contrairement à ce que l'on entend, le big-data ne révolutionne pas l'accès aux données, il tombe juste au bon moment, celui du changement des mentalités sur la conservation pour soi des données ou leur ouverture dans ce monde ultra-connecté qui se construit. C'est l'outil à la mode qui surfe sur cette vague, ça en fait l'outil adapté.
Mais l'ouverture des données auraient très bien pu se faire depuis longtemps même avec les bases relationnelles.
De plus le big-data n'est, en réalité que l'agrégation de données hétéroclites à priori sans relations entre-elles qui la plupart du temps sont stockées individuellement dans des bases de données bien plus classique.
Si tu es sur une grosse base relationnelle, et si tes développeurs poussent pour passer à NoSql c'est, soit qu'ils n'ont pas vraiment approfondit le concept, soit qu'ils n'ont pas vraiment étudier comment l'intégrer et ce qu'il pourrait apporter au projet, soit au contraire c'est bien étudié et c'est, en réalité, un projet parallèle pour donner une autre approche des données mais sans doute pas en remplacement de la grosse base Oracle.

D'ailleurs, il n'est pas rare (et je ne parle évidemment pas de projets vraiment spécifiques type moteur de recherche à la google ou là, le nosql a toute sa place) de voir une base de données, et un moteur NoSql, MongoDB par exemple, en parallèle, comme en surcouche d'une base de données relationnelle plus classique, base de données qui d'ailleurs est, la plupart du temps est sous Oracle, SQLServer, PostGreSQL ou MySQL pour donner un nouveau point d'entrée mais sans pour autant supprimer les classiques relationnels.

Attend encore quelques années, la mode NoSql retombera à sa juste place. Très probablement d’ailleurs, il n'existera plus de bases purement NoSQL, mais tous les SGBD classiques intégreront un moteur NoSQL, c'est d'ailleurs en cours.
SQLServer sera toujours là, PostGreSQL aussi. Oracle ? Probablement aussi, on verra dans quel état. Ils ont encore les moyens de réagir, mais il est certain qu'ils seront de toute façon désormais à l'avenir, obliger de partager le gâteau.
Oracle a perdu énormément en image de marque il y a quelques années, non pas sur son SGBD phare, mais avec le rachat de SUN et l'année de flottement qui s'en est suivi concernant l'avenir de Java et de MySQL. Cela à grandement nuit à l'image et a très certainement accélérer le mouvement d'abandon.
Je connais personnellement plusieurs cas dans mon entourage où cet épisode a été le réel déclencheur de la migration vers SQL Server qui, jusque là, jouait plutôt à l'Arlésienne

[StringBuilder]

use master
go
create procedure dbo.test as

DECLARE @command as varchar(1000), @i int
SET @i = 0
WHILE @i < 5
BEGIN
Print 'I VALUE ' +CONVERT(varchar(20),@i)
EXEC(@command)
SET @i = @i + 1
END

ben ca fait vraiment pas rever, et ca me ramene a environ 25 ans en arriere.

Euh... Ok, vous postez un code (de merde) sans le comparer à son équivalent Oracle.
Peut-être que votre intervention n'est pas complètement objective, si ?

Car ayant fait quotidiennement du PL/SQL et du T-SQL, mise à part les ; qui sont dispensables (mais qu'on peut garder) en T-SQL et les : qui deviennent des @, je ne vois pas de différence flagrande dans les deux notations.

Je pense que vous pêchez avant tout par votre ignorance et certainement encore plus par votre incapacité à penser ensembliste (car des procédures avec des WHILE quant une simple CTE permet de s'en passer, ça doit plus exister ailleurs que dans votre code depuis 15 ans).

[elsuket]

En plus de ce que dit StringBuilder sur la qualité de votre code, quel est l'intérêt de la variable @command ?

@++