Discussion :

[Fabien Celaia]

Tu es sûr que le grid control est payant ???

Non !

[Fabien Celaia]

Nous avons la version SQL Server enterprise 2000 et la 2005 (qui n'a ete validée dans la société que depuis septembre 2008).
Les versions d'Oracle validées sont la 9iR2 et 10gR2 uniquement sous Unix.

Les rares fois ou nous avons perdus des données (c'est tres rare hein... c'est pour ca que je ne critique pas SQL Server, quand y a pas de soucis c'est nickel) c'etait à cause de plantages de disques sous windows et à chaque fois Microsoft a été incapable de nous aider... leurs seules réponses c'est : "re-installez le systeme et restaurez les sauvegardes".
Sauf que sur des bases à haute disponibilité, arreter le service pour restaurer les données, c'est pas toujours possible (sur certaines bases l'arret de service ne doit pas dépasser 2h par mois)...

C'est pour ca que les bases "vitales" dans la société ou je bosse (tres grand compte) ne sont certainement pas sur autre chose que de l'Unix/Oracle.

Mais comme je dis plus haut, il ne faut, à mon avis, pas comparer les SGBD car ils ont tous leur utilité dans une société.

C'est surtout que dans ce cas, le support est nul !
Hormis en de très rares cas de perte de disques + crash, je n'ai encore expérimenté aucun cas où l'on n'a pas pu remonter la quasi totalité des données... si une stratégie de sauvegarde (ou, au besoin, de haute dispo) est installée et appliquée.
En tout cas, lors de pertes, c'est diagnostiquable...

[SQLpro]

Pourquoi ne passent-il pas à l'unicode?

Unicode n'a rien à voir avec les collations. Il faut à la fois l'un et l'autre pour faire fonctionner cela ! Et les NLS d'oracle sont à mille lieues de faire ce qu'une collation permet. Bref, 17 ans de retard... c'est beaucoup !

Ben oui, c'est pas un SGBDR à vocation de démo ou de cours, mais bien plutôt de l'opérationnel...

Sauf que cela a un fort impact sur les façon de verrouiller et qu'en cette matière SQL Server est beaucoup plus souple, notamment depuis la version 2005 qui a singé le comportement par défaut d'Oracle en matière d'isolation par snapshot (encore une chose hors norme d'ailleurs).

Disons qu'ils ont la masse critique pour le faire... qu'ils le corrigent, lentement, contraints et forcés par leurs clients... mais qu'entre le normatif pur et les richesses fonctionnelles, le marché semble avoir choisi...

Çà n'est pas une raison. C'est ce qui a planté IBM dans les années 80. C'est ce qu'à voulu faire MS dans les années 90 et qu'il a remis en cause dans les années 2000. C'est ce qui plantera Oracle s'il ne change pas. Les mêmes causes ayant les mêmes effets d'ailleurs et le libre poussant vers la norme Il est a remarquer que MySQL a la même attitude, mais dans un autre genre (on sait pas faire donc on fait autre chose...) et les problèmes sont les mêmes...

Sur les bugs, ils sont proportionnels à la richesse fonctionnelle, et architecturalement parlant, Oracle a le poid des ans à porter...

La richesse fonctionnelle est aujourd'hui la même avec la version 2008 de MS SQL que d'Oracle. L'inconvénient d'Oracle, qui en fait aussi son attrait c'est le dédoublement du code du fait des multiples OS. Donc naturellement plus de bugs. Mais ce n'est certes pas un avantage !

je persiste à croire, jusqu'à preuve du contraire, que l'allocation et surtout la délocation des ressources est plus propre sur Unix (encore faut-il déterminer lequel) que Windows.

Ce qui était vrai du temps de Windows 2000 est aujourd'hui largement obsolète. Un seul exemple : il est possible d'écrire du code SQL en java intégré à Oracle. Or c'est une machine java externe à oracle qui l'exécute, sans qu'Oracle puisse réellement contrôler ce qui se passe. Cela lui a vallu de graves déboires dans une précédente version. En revanche dans SQL Server la mchine virtuelle SQL CLR tourne sous le contrôle et dans l'environnement mémoire de SQL Server et ce dernier est même capable de tuer certains process sans toucher aux autres si d'aventure cela devenait dangereux pour le noyau SQL...

Quant aux remarques sur les développement, je pense que l'on pourra trouver plein d'appli MS-SQL/VB développées avec les pieds, et a contrario des appli Java sur Oracle fonctionnant parfaitement...

Dans les années 2000 j'ai été payé pour le voir. Un géant de la grande distrib voulait tâter de l'internet. Il a mis des millions sur la table pour créer 6 sites web avec 3 technologies différentes et 6 SSII :
2 sites PHP/MySQL
2 sites Java/Oracle
2 sites ASP/SQL Server
le résultat a été sans discussion :
1) PHP/MySQL : projet fini dans les temps, aucun des sites n'a résisté à la montée en charge
2) Java/oracle : aucun des projets terminés en temps (estimation du temps restant : 40 %)
3) ASP/SQL Server : projets terminé en temps et supportant la charge.

Souvenez-vous des sites de carrefour d'alors (ooshop, carefour direct, carrefour multimedia, verywine) en regard de ceux d'Auchan par exemple...

A +

[Pomalaix]

Pour moi qui enseigne les bases de données relationnelles et le langage SQL l'un des TRES GROS inconvénient d'oracle est son aspect totalement anormatif.

Totalement ? Tu n'as pas l'impression d'être un poil excessif pour dire qu'Oracle n'est conforme à la norme qu'à 80% ?

je veux dire par là qu'il ne respecte pas la norme et fait cavalier seule (à tort) sur des choses très importantes.
1) le gestion des niveaux d'isolation des transactions
2) les collations
3) les transactions DDL
4) le type Datalink
...

Les transactions DDL, effectivement, ce serait une fonctionnalité sympathique. Si ça se trouve, ça sera dans Oracle 12.
Quant au type DATALINK, Oracle propose depuis des lustres le type équivalent BFILE.

Par exemple il est impossible de faire comprendre ce que sont les anomalies transactionnelles telles que lecture impropres, lecture non répétable ou encore lignes fantômes lorsque l'on se limite à deux niveaux d'isolation sur 4 que donne la norme. Ainsi je ne puis faire la démo à mes étudiants qu'avec SQL Server (lire la démo : http://sqlpro.developpez.com/isolation-transaction/).

Comme disait Fadace, l'utilité première d'un SGBD n'est pas de donner des cours ni d'illustrer tel ou tel aspect théorique, mais de faire tourner des applications de la vraie vie dans une véritable entreprise.
Or je n'ai jamais entendu quelqu'un dire qu'il était passé à SQL Server parce que qu'Oracle ne supporte pas la fonctionnalité essentielle que serait la lecture impropre !
Mais même dans une perspective didactique, dès qu'on évoque ce concept (qui se comprend fort bien sur papier, pas besoin de SQL Server), c'est pour ajouter qu'on doit l'éviter à tout prix, et proscrire le mode READ UNCOMMITTED.

Quand à l'absence de la gestion des collations...

La notion de "collation" n'est certes pas d'usage explicite courant sous Oracle, mais n'est pas pour autant inexistante. http://download.oracle.com/docs/cd/B...htm#sthref1910
Je serais curieux d'avoir les détails de ces problèmes, afin de juger en quoi Oracle était incapable de répondre aux contraintes.

[pachot]

Bonjour SQLpro,

Quelques points ne me paraissent pas juste:

Anomalies transactionnelles:
- lecture impropre: n'existe pas. c'est vrai. c'est plutot mieux d'assurer la consistence d'une requête sans rien avoir à vérouiller, non ?
- lecture non répétable: tu peux faire la démo (permis en niveau d'isolation READ COMMITED, évitées en SERIALIZABLE ou avec SELECT FOR UPDATE)
- lignes fantômes: tu peux faire la démo (permis pour tous les niveaux d'isolation, évitées avec LOCK TABLE)

Collations:
voir NLS_SORT et NLS_LANGUAGE (c'était déjà en 8i)

CONNECT BY: très performant, existe depuis les premières versions d'oracle.

CTE: 'vient enfin, péniblement d'introduire' ça fait pas loin de 10 ans la 8i, non ?

Cordialement,
Franck.

[Vincent Rogier]

...le langage SQL l'un des TRES GROS inconvénient d'oracle est son aspect totalement anormatif...

Quelle prose totalement désinformative !!
Oui, Oracle n'est pas 100% conforme à la norme, on le sait. Et on sait aussi que ce n'est pas le sgbd le plus conforme SQL3...
Mais de la à qualifier Oracle "totalement anormatif" , ca me fait marrer....
SQL Server n'est pas 100% conforme lui aussi... Peut être plus, ca je n'en sait rien...
Au moins avec Oracle, on connait le niveau de conformance SQL3 ultra précisement car c'est décris dans leur doc et cela se trouve depuis google...
Par contre, j'ai beau chercher des infos sur la conformance de SQL Server sur le net, je trouve rien....

...Il n'est qu'a regarder deux des sites les plus visités en France. Le premier http://www.voyages-sncf.com/ est développée en Oracle Java est se trouve être farci des plus important bugs de tous les sites web....

Tu semble l'aimer cet exemple, ! Tu le ressort partout ou tu passes...
Comme si c'était la faute d'oracle si les codeurs java de la boite, à qui la SNCF soutraite le site, font du sale boulot...
C'est peut être ma faute, pendant que l'on y est...

[Invité]

Vincent, tu oublies la première partie du post:

Pour moi qui enseigne les bases de données relationnelles et le langage SQL l'un des TRES GROS inconvénient d'oracle est son aspect totalement anormatif.

Dans ce cas précis, je n'ai pas grand chose à dire, sauf que l'université française a toujours beaucoup de mal à sortir du théorique pour se confronter au réel - je ne ressortirais pas toutes les incongruités absconses que j'ai pu entendre au cours de mes études...

Et pour ce qui est de MS Sql Server, pour travailler avec de plus en plus, j'avoue que le côté user-friendly des interfaces est bien agréable avec une robustesse confortable et appréciable, mais dès que l'on rentre dans la documentation avec des problèmes assez fancy, on regrette Oracle, c'est moins friendly, mais c'est bien documenté...

[Waldar]

CONNECT BY: très performant, existe depuis les premières versions d'oracle.
CTE: 'vient enfin, péniblement d'introduire' ça fait pas loin de 10 ans la 8i, non ?

C'est vrai que connect by existe dès 1979 (Oracle v2) et les CTE sont arrivées dans la norme de SQL:1999 si je ne me trompe pas.

Celà dit, l'implémentation des CTE a eu lieu en 9i je crois mais de manière incomplète : on ne peut pas faire de récursivité à l'intérieur de celles-ci.
Ce ne sera implémenté qu'en version 11.2 prévue fin 2009, donc oui il y a bien 10 ans de retard sur cette fonctionnalité associée aux CTE.

Si Oracle a trainé des pieds c'est j'imagine parce que la fonctionnalité de hierarchie était déjà couverte par CONNECT BY.

L'inconvénient d'Oracle, qui en fait aussi son attrait c'est le dédoublement du code du fait des multiples OS. Donc naturellement plus de bugs. Mais ce n'est certes pas un avantage !

Il m'a semblé lire chez Tom Kytes qu'Oracle est codé en C : il "suffit" de compiler dans les différents environnements pour que le gros de l'application fonctionne. J'imagine qu'il y a bien entendu des développements spécifiques à chaque OS, mais je ne pense pas que ce soit une vraie démultiplication de code.

De mon côté j'ai une plus longue expérience SQL avec Oracle qu'avec SQL Server.
Je travaille dans la BI donc quand j'interviens les applications sont déjà terminées.

Ce que je trouve déroutant avec SQL Server ce sont les paramètres par défaut suivants :
- commit implicite si on ne déclare pas de transaction
- pas de format de date explicite (convert avec des type 101 102 et cetera, ou cast depuis les paramètre locaux si j'ai bien tout suivi)
- typage de donnée conservé sans regarder l'opérateur : 5/2 = 2
- collation CI plus ou moins par défaut : 'Aeé' = 'aEÉ'
- rtrim plus ou moins par défaut également : 'A' = 'A '
- un peu de retard en SQL sur Oracle (les analytiques de SQL:2008, expressions régulières en SQL natif, la clause model non normative)

Si j'ai dis des inepties n'hésitez pas à me reprendre ça améliorera mon quotidien !

Au niveau administration n'étant pas DBA de mon expérience les DBA m'ont remonté un discours assez équivalent : les bases SQL Server sont moins surveillées et posent moins de problème que les bases Oracle. Pas de soucis de robustesse ni de performance (environnement quasi full windows même pour Oracle).

Pour finir, à SQL équivalent, sur ce bout de code particulier Oracle va deux fois plus vite et SQL Server deux fois moins vite, sans vraiment avoir d'explication.

[orafrance]

Ce qui est super avec les posts de SQLPro, c'est qu'au moins ça relance le débat A chaque fois qu'il poste une de ses proses ça déchaine les passions

[orafrance]

Dans ce cas précis, je n'ai pas grand chose à dire, sauf que l'université française a toujours beaucoup de mal à sortir du théorique pour se confronter au réel - je ne ressortirais pas toutes les incongruités absconses que j'ai pu entendre au cours de mes études...

Sauf qu'en l'occurence, avant d'être prof il est d'abord un professionnel. De fait, on peut se féliciter que les écoles recrutent enfin des profs qui tatent de la vraie vie

mais dès que l'on rentre dans la documentation avec des problèmes assez fancy, on regrette Oracle, c'est moins friendly, mais c'est bien documenté...

Je suis complétement d'accord. C'est un avantage d'Oracle et un défaut de SQL, la doc chez Oracle est tout simplement impressionnante à tout le point de vue : clarté des explications, exemples, scripts, etc... chez MS non seulement le site est un foutoir pas possible mais c'est pour le moins assez light dés qu'on cherche des choses qui sortent un peu de l'ordinaire.

[DevNico]

Ce qui est super avec les posts de SQLPro, c'est qu'au moins ça relance le débat A chaque fois qu'il poste une de ses proses ça déchaine les passions

Mais il faut aussi remarquer qu'en tant que "Microsoft Most Valuable Professional", il doit naturellement avoir certains réflexes un peu conditionnés lors qu'il voit des discussions portant sur Oracle / SQL Server.

J'aimerais bien avoir l'avis d'un "Oracle Most Valuable Professional" maintenant

Quand on a investi du temps dans un domaine, on va naturellement avoir un petit penchant pour le promouvoir (je parle en connaissance de cause)

Nicolas

[Pomalaix]

Ce que je trouve déroutant ce sont les paramètres par défaut suivants :
- commit implicite si on ne déclare pas de transaction
- pas de format de date explicite (convert avec des type 101 102 et cetera, ou cast depuis les paramètre locaux si j'ai bien tout suivi)
- typage de donnée conservé sans regarder l'opérateur : 5/2 = 2
- collation CI plus ou moins par défaut : 'Aeé' = 'aEÉ'
- rtrim plus ou moins par défaut également : 'A' = 'A '
- un peu de retard en SQL sur Oracle (les analytiques de SQL:2008, expressions régulières en SQL natif, la clause model non normative)

Si j'ai dis des inepties n'hésitez pas à me reprendre ça améliorera mon quotidien !

Bonjour

Dans le principe, un paramètre "par défaut" suggère qu'il est modifiable. Si dans les différentes options, on retrouve celle qui nous convient, ce n'est pas bien méchant.
Pour revenir à vos exemples :

commit implicite si on ne déclare pas de transaction

Je ne vois pas de quoi il s'agit. Sous Oracle, il n'existe aucune commande pour déclarer explicitement une nouvelle transaction.

pas de format de date explicite (convert avec des type 101 102 et cetera, ou cast depuis les paramètre locaux si j'ai bien tout suivi)

101 102, qu'est-ce que c'est que ça ??
Le paramètre de session NLS_DATE_FORMAT est tout ce qu'il y a d'explicite.

typage de donnée conservé sans regarder l'opérateur : 5/2 = 2

J'aimerais bien que ce soit le cas ! Mais sur ma 10g :
SQL> select 5/2 from dual;

5/2
----------
2,5

collation CI plus ou moins par défaut : 'Aeé' = 'aEÉ'

Ca c'est complètement faux.

rtrim plus ou moins par défaut également : 'A' = 'A '

C'est exact sur les types CHAR et les constantes (qui sont interprétées comme des CHAR), mais pas pour les VARCHAR2.

[Waldar]

Les points abordés concernent SQL Server par rapport à Oracle
J'ai édité mon post qui manquait de clarté.

[Pomalaix]

Les points abordés concernent SQL Server par rapport à Oracle
J'ai édité mon post qui manquait de clarté.

Argh, je me suis fait avoir !
Comme le sujet c'est "avantages et inconvénients d'Oracle", je n'ai pas pensé une seconde que vous critiquiez SQL Server...

[Waldar]

Les inconvénients de SQL Server par rapport à Oracle sont aussi les avantages d'Oracle par rapport à SQL Server (pirouette ?).
Mais ce n'était pas clair, sincèrement désolé.

[voran]

Pour moi qui enseigne les bases de données relationnelles et le langage SQL l'un des TRES GROS inconvénient d'oracle est son aspect totalement anormatif. je veux dire par là qu'il ne respecte pas la norme et fait cavalier seule (à tort) sur des choses très importantes.
1) le gestion des niveaux d'isolation des transactions
2) les collations
3) les transactions DDL
4) le type Datalink
...

C'est FAUX ARCHI FAUX !!! Il ne s'agit que d'un avis très personnel et engagé.
AUCUN EDITEUR SGBD NE RESPECTE REELLEMENT LA NORME.

Quand à l'absence de la gestion des collations, elle a obligé certains très grand compte de passer d'Oracle à SQL Server pour des sites web internationaux multilangues pour lesquels il était exigé de mélanger les différentes cultures de langue au sein d'une même table avec la possibilité de faire un tri en fonction de la culture de langue de l'utilisateur (Arabe, cyrillique, chinois, anglais...).

J'ai l'intime conviction que ce grand compte n'a pas cherché bien loin et a profité cette fausse occasion pour passer chez bill.

Je trouve Oracle particulièrement incohérent dans les choix technologiques qui ont été faits à la va vite et qu'Oracle tente maintenant et un peu tard de réparer, comme les requêtes récursives avec CONNECT BY alors que la norme c'est la CTE et qu'Oracle vient enfin, péniblement d'introduire.
Cela me fait penser à IBM dans les années 70 : je suis le standard, et les autres je les emmerdent...

Et à part le CONNECT BY que l'on retrouve dans la majorité de tes posts et pas forcément utile dans tous les projets ?

Enfin sur la volumétrie, SQL Server compte actuellement plusieurs centaines de bases de données de plus de 10 To. Même si Oracle et DB2 tiennent le haut du pavé en matière de VLDB, cela ne tient qu'à un seul fait : l'ancienneté sur le marché.

Si c'était vrai, les NOUVELLES INSTALL de serveur UNIX/ORACLE ne seraient pas si nombreuses.

En effet la fiabilité de SQL Server sur plateforme Windows est actuellement considérée comme supérieure aux divers Linux et Unix.

Considérée par SQLpro ?

Quand à la sécurité, SQL Server est en avance sur Oracle depuis quelques années, alors que dans les années 90 Oracle était considéré comme unbreakable (mais ce n'était qu'un slogan !).

Il y a en effet de plus en plus de rumeurs suspectes à ce sujet sur la toile.
Quels sont les faits réels ???

Enfin le dernier point est le coût d'Oracle à tous les niveaux.

Et pourtant SQL Server rame toujours autant pour copier et tenter de rattraper ORACLE
Étrange non ?

Les ressources serveurs nécessaires aux instances Oracle sont très gourmandes et souvent de façon injustifiées.

Du coup j'ai un doute sur ce que tu appelle VLDB et SQL SERVER

Les licences sont exorbitantes (8 à 12 fois plus cher que MS) et le coût d'administration, comme de développement est d'environ 20 à 30 % plus cher que MS, ce qui fait qu'au total le TCO est 30% supérieur à celui de MS.

Seul point noir qui n'empêche pas ORACLE d'écrabouiller la concurrence.
On en arrive même a entendre que le grid control est payant tellement ORACLE a la réputation d'être cher !
Encore une fois, en tant que partenaire MICROSOFT et ORACLE, les coûts sont négociables et quasi identiques ... à fonctionnalité équivalentes !

.... Le second www.fnac.com est développé en SQL Server / .net et ne connais ni contre performances ni bug.

Et la marmotte ???

e premier http://www.voyages-sncf.com/ est développée en Oracle Java est se trouve être farci des plus important bugs de tous les sites web. Le second www.fnac.com est développé en SQL Server / .net et ne connais ni contre performances ni bug. Lequel coute le plus cher à développer et entretenir ?

Et si on développait le site de voyages-sncf.com avec SQLServer / .NET histoire de comparer avec OBJECTIVITÉ !

[Pomalaix]

On en arrive même a entendre que le grid control est payant tellement ORACLE a la réputation d'être cher !

C'est peut-être parce que, concrètement, le produit de base Grid control, certes inclus dans la licence du SGBD, ressemble assez à une coquille vide tant qu'on n'y a pas adjoint les modules intéressants que sont "tuning pack" ou "diagnostics pack". Malheureusement, ces derniers sont facturés à prix d'or.

Encore une fois, en tant que partenaire MICROSOFT et ORACLE, les coûts sont négociables et quasi identiques ... à fonctionnalité équivalentes !

Au vu de récents témoignages de collègues, il semble qu'Oracle devienne psychorigide et parano vis à vis des licences, s'arrogeant le droit de venir les vérifier sur site, refusant la discussion et notifiant par lettre comminatoire des redressements fort discutables pour des serveurs censément accédés en mode Web.
Je comprends et je soutiens ceux qui les quittent, ces tarifs exorbitants conjugués à une politique commerciale désastreuse ne peuvent pas rester sans conséquence.

[orafrance]

Il y a en effet de plus en plus de rumeurs suspectes à ce sujet sur la toile.
Quels sont les faits réels ???

Une recherche rapide sur le net t'éclairera, j'en ai aussi parlé dans ce topic, je t'invite à remonter dans les pages pour avoir plus d'élément.

SQL Server base toute la sécurité sur la sécurité de l'OS qui, si on sort des a priori et troll habituelle, reste robuste si tant est qu'on prenne le temps de bien faire les choses (comme sous Unix du reste). L'une des grosses faiblesses d'Oracle c'est notamment l'usage du java sauce Oracle qui applique bien moins rapidement les patchs de sécurité du java de Sun. On peut espérer que ça change grâce à la fusion d'Oracle avec Sun
En général, ce qui est le plus problématique c'est la lenteur d'Oracle à corriger les failles découvertes

Et pourtant SQL Server rame toujours autant pour copier et tenter de rattraper ORACLE
Étrange non ?

C'est une affirmation gratuite, dans quel domaine Oracle surpasserait-il tant Microsoft ? Un seul exemple, je préfère largement faire du mirroring sous SQL Server que mettre en place le cauchemardesque Data Guard

On en arrive même a entendre que le grid control est payant tellement ORACLE a la réputation d'être cher !

C'est juste un abus de langage, comme le dit Pomalaix, le Grid gratuit a une utilité plus que limitée et les options sont pas données
Ceci étant dit, j'ai pas trouvé de console aussi claire sous SQL Server.

[orafrance]

[Mode modérateur ON]

Merci d'éviter les affirmations à l'emporte pièce et les excès de majuscules qui ne font qu'ajouter de la tension au sujet.

Exemple :

C'est FAUX ARCHI FAUX !!! Il ne s'agit que d'un avis très personnel et engagé.
AUCUN EDITEUR SGBD NE RESPECTE REELLEMENT LA NORME.

Qu'on prétende qu'une personne se trompe ne me dérange pas, qu'on le fasse ainsi sans argumenter (4 points cités et tout est rejeté en bloc), c'est inacceptable.

Restons entre gentlemen et pensons aux décideurs qui passeront sur ce sujet pour se faire une opinion. Merci de modérer vos ardeurs. Allez prendre l'air 5 minutes avant de répondre à un message qui vous a particulièrement heurté si besoin

[Vincent Rogier]

J'appuie fortement la remarque d'OraFrance et essayons tous d'être objectif et de n'apporter que des contributions utiles à ce débat.

Cela vaut pour tout le monde, quelque soit son statut !

Le post de SqlPro a poussé au troll et aux réactions subjectives car bien qu'en apportant des arguments réels, il était partiellement hors sujet, très subjectif et limite désinformatif.
Mais bon, cela a au moins eu le mérite de relancer le débat.

Restons raisonnables et et focalisés sur la thématique du débat !