Quel SGBD choisir : Oracle ou Microsoft SQL-Server ?

Le , par dellibmdell, Nouveau Candidat au Club
Dois-je choisir Oracle ou MS SQL-Server?

Qui peut me donner les points forts et les points faibles de chacun de ces SGBD?

En fait je voudrais avoir une idée générale sur les points forts d'oracle comparativement à MS sql/server.

Si je dois les comparer quels sont les points essentiels que je dois aborder.

Merci beaucoup


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de orafrance orafrance - Expert éminent sénior https://www.developpez.com
le 25/05/2009 à 9:48
Il est vrai que si suivre la norme est important, j'ai du mal à voir du mal quand un éditeur ajoute des fonctionnalités supplémentaires comme la jointure externe partitionnée (langue de molière oblige ) qui a un réel intérêt pour le reporting et allège énormément la syntaxe.

Après, on peut pas en vouloir au concurrent de s'être fait "griller" sur certaines notions, faut bien que chacun se différencie et maintenant c'est plus trop sur les qualités techniques qu'Oracle ou MS arriveront à faire la différence tant il me semble évident qu'ils se valent du strict point de vue "core" (gestion des perfs, réplication, haute dispo,...).
Avatar de SQLpro SQLpro - Rédacteur https://www.developpez.com
le 25/05/2009 à 17:04
Je l'ai surtout apprise sur ce forum et notamment grâce à vos papiers et vos interventions très (très très) rigides sur ce point.

Certes je suis rigide, mais il y a une raison essentielle. La plupart des internautes et développeurs pensent avoir appris SQL, alors qu'ils ont appris du MySQL, du Oracle ou du Transact et l'on voir les dégâts que cela cause à tous les niveaux... C'est pourquoi j'ai pris partit de défendre SQL (le langage et donc la norme), car avant tout la norme est faites par les professionnels et se trouve en moyenne plus intelligente que n'importe quel éditeur pris séparément. D'ailleurs le rapporteur de la norme SQL, n'est-il pas Jim Melton, principal conseillé technique pour Oracle ?

Pour le format de date je parlais bien de spécifier le format de l'affichage.

Pour l'affichage ce n'est pas du ressort d'un SGBDR, mais d'un outil client.

Si un fournisseur m'envoie un fichier à intégrer dans le SI, avec des dates par exemple "AAAAMM/JJ", je dois aller regarder dans les tables de convert pour trouver ce qui convient le mieux.
Chez Oracle c'est plus simple avec to_date(<champ>, 'yyyymm/dd').

La récupération de données est du domaine des outil d'ETL et non du SGBDR. Mais sachez cependant que c'est encore plus simple encore sous MS SQL Server, car vous n'avez pas de requête a récrire pour charger les données en fonction du format, ceci étant un paramètre de la session client :
SET FORMAT XXX;
avec XXX pouvant valoir : YMD, YDM, MDY, MYD, DMY, DYM.
Modifiable à tout moment.

Pour les expressions régulières la syntaxe Oracle ne suit pas la norme, mais les fonctions sont bien built-in (après je ne sais pas où elles sont exécutées).

Built-in ou pas ne change rien en terme de fonctionalité. Vous retrouvez la même sous SQL Server via CLR par exemple avec RegexMatches. http://msdn.microsoft.com/fr-fr/magazine/cc163473.aspx

Côté analytiques je pensais surtout aux fonctions en elles-même qui existe chez Oracle et pas encore chez Microsoft pour des raisons de normalisations : "ntile", "lead", "lag", "first_value", "last_value"

ntile existe sous MS, mais les autres sont trop récentes (norme SQL:2008) pour y avoir été déjà implantées.

du côté de fonctions plus anciennes comme "sum", "min", "max", "avg" ne permettent pas d'insérer de tri dans la fonction de fenêtrage et donc pas de somme cumulative,

Ce qui fonctionne aussi chez SQL Server, mais sans la fenêtre RANGE/ROWS. Effectivement c'est une différence que de ne pas pouvoir faire une somme cumulative, mais cela s'écrit très facilement via une CTE qu'Oracle a eu beaucoup de mal à introduire.

...les partitioned outer joins ... la clause model ...

Tout cela est du domaine de l'analytique et s'éloigne fortement du simple transactionnel. Dans ce cas plutôt que de complexifier le SQL de base fait pour des bases OLTP, il suffit d'utiliser un langage qui est un standard de fait comme MDX (Multi Dimensionnal Expression) qui est fait pour cela. Notons qu'a part Oracle qui joue cavalier seul sur ce sujet, presque tous les grand du décisionnel ont adhéré à MDX : SAS, SAP, Proclarity, Cognos, Business Objects...

Pour finir une syntaxe qu'Oracle a récupéré chez SQL Server : PIVOT / UNPIVOT, qui ne sont pas dans la norme non plus (j'ai lu ça dans un de vos posts, et je vois d'ici vos cheveux se hérisser sur votre tête car vous n'aimez pas)

Je n'aime pas car c'est une clause cosmétique. Elle n'apporte rien du tout si ce n'est de repositionner les données. Aucune valeur ajoutée, juste de la peinture...

A +
Avatar de voran voran - Membre averti https://www.developpez.com
le 15/06/2009 à 14:05
Citation Envoyé par SQLpro  Voir le message
Notons qu'Oracle ne sait toujours pas travailler les collation et en est resté avec cette chose immonde qu'est le NLS

Une (même petite) explication s'impose.
Sinon les posts sur developpez font finir en :

- studio management c'est horrible
- l'optimiseur de requête de SQL Server est tout pourri
- Oracle est pas gentil
...

Bref que du bonheur

Avatar de SQLpro SQLpro - Rédacteur https://www.developpez.com
le 15/06/2009 à 17:50
Oracle est pas gentil

Enfin, une vérité vraie !!!

A +
Avatar de voran voran - Membre averti https://www.developpez.com
le 16/06/2009 à 6:47
Citation Envoyé par SQLpro  Voir le message
Enfin, une vérité vraie !!!

A +

C'est bien ce que je pensais

Et à part ça, vous reprochez quoi à NLS ?
Avatar de SQLpro SQLpro - Rédacteur https://www.developpez.com
le 16/06/2009 à 9:36
Et à part ça, vous reprochez quoi à NLS ?

Ne répond pas à la problématique puisqu'est statique : impossible de faire un tri ou une jointure en changeant dynamiquement la collation.

Avec le NLS pouvez vous faire un :
Code : Sélectionner tout
...ORDER BY COL1 NLS Chinese
?

Avec le NLS pouvez vous faire des comparaisons en cahngeant la colation à la volée ?
Code : Sélectionner tout
...INNER JOIN T1.COL1 = T2.COL1 NLS Hebrew
?

C'est une des raisons qui a fait changer certains client d'Oracle à SQL Server car il était impossible de réaliser certains sites web mondiaux nécessitant une telle dynamicité. Un chinois devant pouvoir visualiser et trier ses données en fonction de sa culture de langue et un russe ou un juif (hébreu) de même, alors que les données sont dans la même table...

Lisez l'article que j'ai écrit sur les collations : http://sqlpro.developpez.com/cours/s...er/collations/

A +
Avatar de Waldar Waldar - Modérateur https://www.developpez.com
le 16/06/2009 à 10:04
La réponse aux deux questions est oui, la syntaxe est par contre un peu plus encombrante mais reste compréhensible :

Code : Sélectionner tout
1
2
3
ORDER BY COL1 NLS Chinese 
=> 
ORDER BY NLSSORT(COL1, 'nls_sort=Chinese')
Code : Sélectionner tout
1
2
3
INNER JOIN T1.COL1 = T2.COL1 NLS Hebrew 
=> 
INNER JOIN NLSSORT(T1.COL1, 'nls_sort=Hebrew') = NLSSORT(T2.COL1, 'nls_sort=Hebrew')
Le chapître de la doc Oracle consacré à ce sujet : http://download.oracle.com/docs/cd/B...t.htm#NLSPG005
Avatar de orafrance orafrance - Expert éminent sénior https://www.developpez.com
le 16/06/2009 à 10:10
Et en général c'est l'application qui fait un alter session en fonction du contexte pour éviter d'allourdir les requêtes. Le site web d'Oracle est un parfait exemple pour montrer que l'internationalisation est possible.

Les clients dont tu parles sont entourés d'incompétents c'est tout
Avatar de B.AF B.AF - Membre chevronné https://www.developpez.com
le 17/06/2009 à 11:18
Citation Envoyé par orafrance  Voir le message
Et en général c'est l'application qui fait un alter session en fonction du contexte pour éviter d'allourdir les requêtes. Le site web d'Oracle est un parfait exemple pour montrer que l'internationalisation est possible.

Les clients dont tu parles sont entourés d'incompétents c'est tout

+1. Et dans la majorité des applications qui ont ce genre de besoins, il n'est pas évident qu'il faille le déléguer à la base.

Pareil pour la gestion des dates.

Tout ce qui est écrit relève d'un principe qui est de dire que tous les traitements sont délégués au SGBD.

Ok, mais ce n'est pas nécessairement le cas, j'ai un faible aujourd'hui pour SQL server parce que dans ma structure le TCO est meilleur et globalement nous avons un outil assez transparent et qui monte bien en charge, maintenant, la grande différence entre les deux est qu'ils sont tous les deux un bon choix; la différence réelle est le TCO en focntion de la strucutre et du contexte.

Ce sont deux bons produits, concurrents, mais on davantage à se dire "je préfére" que c'est mieux --> Ca reléve du parti pris et de l'expérience.

C'est très compliqué aujourd'hui de trouver une personne connaissant suffisamment les deux pour trancher le débat. Par ex.; les collations.
Avatar de Jean-Philippe André Jean-Philippe André - Rédacteur/Modérateur https://www.developpez.com
le 24/01/2012 à 10:57
Hello,

je profite de passer pa là pour indiquer en lien un comparatif (en anglais) des deux systèmes sur les aspects techniques et coûts en entreprises:
http://www.alinean.com/PDFs/Microsof...Study_2010.pdf
Ca date de 2010
Avatar de el_muchacho el_muchacho - Nouveau membre du Club https://www.developpez.com
le 06/03/2013 à 23:42
Au passage, la base de données analytique qui écrase les autres en terme de rapport performance/prix est l'allemand EXASol. Non seulement elle renvoie tout le monde dans les 22 mètres dans toutes les catégories où elle participe, mais à 3To et 10To, c'est sans appel. C'est une base distribuée in memory dont les principes semblent assez sains (du peu qu'on puisse en juger): orientée colonne, shared nothing, ACID, SQL. Le meilleur des deux mondes entre les bases distribuées comme Cassandra et les RDBMS. Le problème, c'est qu'en dehors du territoire allemand, EXAsol est pratiquement inconnu. Parmi les clients, DELL cite Sony et Olympus.
Wikipedia indique: "The license model is based on the allocated RAM for the database software (per GB RAM) and independent to the physical hardware. Customers gain the maximal performance if their compressed active data fits into that licenced RAM, but it can also be much larger."

Greenplum est comparable à la fois en technologie et p-ê en performances.
http://www.d1-solutions.com/fileadmi...e_database.pdf

Il reste que les infos sont floues, en particulier, elles prétendent être ACID. N'est-ce pas incompatible avec le fameux théorème PAC ? Qu'advient-il aux perfs si les données ne tiennent pas en RAM ?
Offres d'emploi IT
Ingénieur conception en électronique de puissance H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Consultant sap finance/controlling H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Ingénieur analyste programmeur (H/F)
Safran - Auvergne - Montluçon (03100)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique SGBD & SQL