Discussion :

[voran]

Il semble que cela soit l'inverse aujourd'hui, Oracle étant dans l'incapacité de corriger certains bugs...
http://www.databasesecurity.com/dbsec/comparison.pdf
http://searchsecurity.techtarget.com...232328,00.html
http://www.pcinpact.com/actu/news/32...litchfield.htm
Hélas les chiffres sont impressionnants du manque de sécurité des versions actuelles d'Oracle en comparaison de MS SQL Server !

Il était question de fiabilité et les liens cités ne parle que de sécurité. Point important certe, mais plutôt la tâche des OS et routeurs. Car quand le loup atteind la base il est déjà trop tard.
Donc, ORACLE est au moins aussi fiable sinon plus que SQL Server.

[dbperl]

Ce que Oracle(9i) fait, mais pas MS-SQL(2000)
- gestion cluster (optionnel), haute disponibilité (homis WSB)
- parallélisme pour insert et update (optionel)
- roles définis par l'utilisateur

C'est pas une liste exhausitive... et je me réjouis de la rafraîchir avec les commentaires des autres membres.

Les 3 points cités ci-dessus sont parfaitement gérés par MS SQL (Edition Enterprise pour le cluster et parallélisme)

[chti_juanito]

Quelles sont les différences entre Oracle et SQL-Server en ce qui concerne la gestion des transactions ?

[Fabien Celaia]

Les différences s'écrasent au vue de MS-SQL 2005 et Oracle 10g.

- Oracle se simplifie, MS-SQL se complexifie et devient plus opaque
- reste le monoplateforme de MS-SQL, mais son prix nettement plus attractif.
- le pl-sql, quoique plus difficile à appréhender et manipuler (exec immediate pour ordres DDL, curseur et DBMS_outpucontre simple Select) reste infiniment plus riche que le t-sql

[taupe31]

Bonjour,
ayant une assez bonne experience des bases de données (Oracle, Sybase, SQL Server, ACCESS, MySQL, DB2, etc...), je me permets de donner mon avis.

Comparer Oracle à SQL Server sans connaitre le contexte d'utilisation est impossible.
Ces 2 SGBD ont leurs points forts et leurs points faibles et ne sont, à mon sens, pas en concurrence.

Oracle est bien plus riche en fonctionnalités que SQL Server et le PL/SQL est inifiment plus riche que T-SQL.
Mais tout le monde n'a pas besoin de toutes ces fonctionnalités et ne veut pas se noyer dans des concepts qu'il n'utilisera jamais.

Les grands comptes ont des données sensibles et ces données SQL Server ne peut pas les protéger comme Oracle (meme sous windows, Oracle est beaucoup plus fiable).
Par contre, avoir un Oracle pour gerer des petits volumes de données ou des données non sensibles est une folie et un gachi enorme (en terme d'argent et de perte de temps).
C'est vouloir tuer un moustique avec un bazooka.

Ce qui m'enerve le plus, ce sont les gens qui essaient d'utiliser les mauvais outils pour travailler, qui détournent les outils de leur utilisation.
A chaque metier son outil et le monde tournera rond.

[duc@ti]

Est-il possible de trouver un site sur les correspondances de commandes et de lignes de scripts entre le PL/SQL et le T-SQL ?
Merci,

[SQLpro]

J'ajoute, ce que fais SQL Server et qu'Oracle ne sait toujours pas faire :
les requêtes récursives dans des graphes.
Oracle a toujours été très en retard sur les points essentiels de la norme SQL, comme les jointures dont la clause JOIN n'est apparue qu'avec la version 9, alors que la norme les avaient introduite en 1992 (soit près de 10 ans de retard !).

De même les requêtes récursives ont été normalisées depuis la version 1999 de la norme et sont présente dans Sybase, IBM DB2, SQL Server et même récemment Firebird... Mais toujours pas dans Oracle qui implémente une technique propriétaire à base de CONNECT BY / PRIOR, incapable de traiter les graphes.
Exemple : http://sqlpro.developpez.com/cours/s...te-recursives/

A +

[orafrance]

Mais toujours pas dans Oracle qui implémente une technique propriétaire à base de CONNECT BY / PRIOR, incapable de traiter les graphes.

et terriblement complexe à comprendre

[SQLpro]

C'est marrant hier je viens de donner l'exemple que je cite dans ce papier :
http://sqlpro.developpez.com/cours/s...te-recursives/
un parcours de grpahe avec recherche du plus court chemin, et sur 9 stagiaires, 8 ont compris du prmier coup !

Mais peut être est-ce une question de pédagogie !!! ;-)

A +

[orafrance]

je pensais au CONNECT PRIOR d'Oracle qui n'est pas des plus simple à utiliser

[SQLpro]

Ha oui, mea culpa... Je confirme ! J'ai rien bité1 a cet ersatz de récursivité....

PS : 1 bité au sens informatique du terme (BIT = BInary digiT), c'est à dire que je n'ai pas pu mettre en BIT ce cencept !

A +

[voran]

J'ajoute, ce que fais SQL Server et qu'Oracle ne sait toujours pas faire :
les requêtes récursives dans des graphes.

Ok,
Donc pour ceux qui en ont l'utilité (nombreux ? ) , il y a SQL Server.

Sinon dans la série ce que fait ORACLE et que SQL Server ne sait toujours pas faire :
Les base de données en cluster ACTIF/ACTIF : ORACLE RAC

[orafrance]

sauf erreur MSCS couplé avec SQL Server peut le faire

[gregory.broissard]

je confirme. SQLServer peut faire du Cluster Actif/actif

[Fabien Celaia]

je confirme. SQLServer peut faire du Cluster Actif/actif

Je suis preneur : comment fait-il cela ?? Quelle techno ?
Comment gère-t-il les pages en mémoire sur 2 machines séparées ?
On parle bien d'une base MS-SQL accessible depuis 2 machines spécifiques? Avec un dataserver ou 2 ?

Aussitôt prouvé, je corrige de facto mes critiques sur le sujet.

[Zicson1]

Le choix d'un Système de Gestion de Base de Données est fonction de l'architecture et du cahier de charges de notre application que nous voulons réaliser car en matière d'importance elles se valent, pour une Base de données très grande et importante l'usage de ORACLE est évidente car nous connaissons sa puissance de stabilité et une grande compatibilité des structures SQL, car il peut y avoir des structures SQL qui ne puisse pas être excecuter sou SQL serveur mais cela ne met pas en cause l'utilisation de SQL serveur car il est très utile pour certaines applications. Moi personnellement j'utilise INTERBASE. si on me demandait de les classer par ordre de grandeur, je commencerais par ORACLE, INTERBASE, SQL SERVEUR, MYSQL,.......

[orafrance]

car il peut y avoir des structures SQL qui ne puisse pas être excecuter sou SQL serveur

Tu as des exemples ? Parce que SQL Serveur respecte mieux la norme qu'Oracle

Et pour les très grosses bases SQL ou Oracle sont équivalent

[SQLpro]

car il peut y avoir des structures SQL qui ne puisse pas être excecuter sou SQL serveur mais cela ne met pas en cause l'utilisation de SQL serveur

J'aime beaucoup lire ce genre de choses, car elles sont fausses et montrent que leurs auteurs n'ont pas prit le temps de vérifier leurs propos.

Par exemple Oracle est incapable de faire des requêtes récursives. En effet, la récursivité du SQL a été introduite avec la norme SQL:1999. Cette technique (CTE, voir la papier que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/s...te-recursives/) est implémenté sur DB2, Sybase, Interbase, SQL Server, mais pas sous Oracle qui utilise une syntaxe propriétaire à base de CONNECT BY / PRIOR incapable de traiter la majorité des cas de figure de la récursivité.
Il y a bien d'autres choses qui sont strictement antinormatif dans Oracle : DECODE, TO_CHAR, TO_DATE...
En revanche Oracle est plus pointu sur les fonctions analytiques que SQL server 2005....

Enfin en ce qui concerne la sécurité, triste nouvelle Oracle semble bien avoir perdu la main au profit de SQL Server : http://www.databasesecurity.com/dbsec/comparison.pdf
http://www.pcinpact.com/actu/news/32...litchfield.htm

A +

[jmguiche]

J'aime beaucoup lire ce genre de choses, car elles sont fausses et montrent que leurs auteurs n'ont pas prit le temps de vérifier leurs propos.

Par exemple Oracle est incapable de faire des requêtes récursives. En effet, la récursivité du SQL a été introduite avec la norme SQL:1999. Cette technique (CTE, voir la papier que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/s...te-recursives/) est implémenté sur DB2, Sybase, Interbase, SQL Server, mais pas sous Oracle qui utilise une syntaxe propriétaire à base de CONNECT BY / PRIOR incapable de traiter la majorité des cas de figure de la récursivité.
Il y a bien d'autres choses qui sont strictement antinormatif dans Oracle : DECODE, TO_CHAR, TO_DATE...
En revanche Oracle est plus pointu sur les fonctions analytiques que SQL server 2005....

Enfin en ce qui concerne la sécurité, triste nouvelle Oracle semble bien avoir perdu la main au profit de SQL Server : http://www.databasesecurity.com/dbsec/comparison.pdf
http://www.pcinpact.com/actu/news/32...litchfield.htm

A +

Oui, il est assez amusant que la norme c'est faite en prenant en compte des fonctionnalités n'existant nulle part ou presque au moment de ses sorties et qu'elle n'a pas pris des fonctionnalités présentes sous oracle depuis 1987 au moins (V5).
C'est Oracle qui est "antinormatif" ou la norme qui est "anti oracle" ?

Je traite des problèmes de récusivité assez complexes et je ne suis pas sur de pouvoir les traiter avec la norme alors qu'avec des pipeline function, c'est du gateau et ça va vite.

Je ne sais pas si la maniere d'oracle de traiter les fonctions analytiques ou les algorithmes de blast est ou sera dans la norme, en attendant, je suis bien content de les avoir.

C'est plus important, pour moi, d'avoir eu decode et connect by depuis 87 plutot qu'avoir été à la norme, c'est plus important, pour moi, d'avoir des pipeline function plutot qu'etre à la norme, c'est plus important, pour moi, d'avoir des fonctions statistiques plutot qu'etre à la norme, etc.

Je fais des projets souvent complexes, avec beaucoup de calcul coté base, donc soit en PL, soit en Transac, donc pas portable. La norme n'est donc pas un probleme, ce qui compte, amha, c'est fiabilité, productivité, performance.

[orafrance]

Je peux comprendre tes doutes sur la norme mais faut quand même savoir qu'il y a un paquet de personne qui travaille dessus ce qui permet de dégager des besoins et les meilleures méthodes pour y réponde. C'est pas une lubie d'une élite qui veut se faire connaitre.

Oracle propose effectivement des alternatives pour répondre à ces besoins mais c'est souvent plus des rustines qu'autre chose... en parlant de CONNECT BY, si c'était si parfait Oracle ne l'aurait pas enrichit avec la 10g... et les pipelines c'est un moyen technique pour pallier les carences du moteur, ça ne facilite pas la lecture du code et surtout ça oblige à faire appel à du PL/SQL quand le SQL pourrait suffire.

D'ailleurs, Oracle est lui-même conscient du besoin de revenir à un SGBD normé puisqu'il s'attache de plus en plus à respecter la norme ANSI