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...
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 !
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).
Çà 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...
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 !
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...
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 +
Totalement ? Tu n'as pas l'impression d'être un poil excessif pour dire qu'Oracle n'est conforme à la norme qu'à 80% ?
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.
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.
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.
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.
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....
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...
Vincent, tu oublies la première partie du post:
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...Envoyé par SQLpro
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é...
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.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 ?
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.
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.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 !
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.
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
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
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.
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
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 :
Je ne vois pas de quoi il s'agit. Sous Oracle, il n'existe aucune commande pour déclarer explicitement une nouvelle transaction.
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.
J'aimerais bien que ce soit le cas ! Mais sur ma 10g :
SQL> select 5/2 from dual;
5/2
----------
2,5
Ca c'est complètement faux.
C'est exact sur les types CHAR et les constantes (qui sont interprétées comme des CHAR), mais pas pour les VARCHAR2.
Les points abordés concernent SQL Server par rapport à Oracle
J'ai édité mon post qui manquait de clarté.
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é.
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.
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.
Et à part le CONNECT BY que l'on retrouve dans la majorité de tes posts et pas forcément utile dans tous les projets ?
Si c'était vrai, les NOUVELLES INSTALL de serveur UNIX/ORACLE ne seraient pas si nombreuses.
Considérée par SQLpro ?
Il y a en effet de plus en plus de rumeurs suspectes à ce sujet sur la toile.
Quels sont les faits réels ???
Et pourtant SQL Server rame toujours autant pour copier et tenter de rattraper ORACLE
Étrange non ?
Du coup j'ai un doute sur ce que tu appelle VLDB et SQL SERVER
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 !
Et la marmotte ???
Et si on développait le site de voyages-sncf.com avec SQLServer / .NET histoire de comparer avec OBJECTIVITÉ !
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.
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.
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
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
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.
[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 :
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.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.
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
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 !
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager