Ben... les requettes dynamyques et le DDL, en PL, ça se fait...
Et j'apprecie le coté tres structuré de PL, la gestion des exceptions... Transac a évolué dans ce sens ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Ben... les requettes dynamyques et le DDL, en PL, ça se fait...
Et j'apprecie le coté tres structuré de PL, la gestion des exceptions... Transac a évolué dans ce sens ?
bien sûr mais au prix de sacré migraine dans certains cas : requête de plus de 32000 caractères, quote à doubler, commit du DLL, etc...
Pas à ma connaissance et je le regrette...Envoyé par jmguiche
J'ai plus d'affinité pour le Transact (simple question d'habitude), mais je trouve effectivement PL/SQL mieux pensé sur plusieurs points, et surtout la gestion d'exceptions.
Par contre il y a une chose dont je suis sûr, c'est qu'on fait aussi vite de gros plats de pâtes avec l'un qu'avec l'autre
Bonjour,
Voici un article intéressant :
Oracle 10g vs. MS SQL Server 2005 - Features, strengths and weaknesses comparison between Oracle 10g and MSSQL 2005 (Yukon) databases.
Tous les points ne sont pas évoqués mais je ne suis pas d'accord avec tous les commentaires [...] cela reste globalement une comparaison honnête à mon avis.
J'ai bien aimé le passage sur :
- les index "Oracle provides richer indexing options than MSSQL 2005 does." ... c'est factuel
- Flashback, audits, échanges asynchrones
Concernant le dernier échange sur le Transact et PLSQL, J'avoue avoir une préférence pour la simplicité du Transact [...] sauf lorsque l'on commence à bidouiller du fait de sa simplicité "relative" (le SQL dynamique est un exemple bien sale).
@+
J'ai tendance à croire que c'est plus un problème de programmeur que de langage !...
Par contre il y a une chose dont je suis sûr, c'est qu'on fait aussi vite de gros plats de pâtes avec l'un qu'avec l'autre
Si ça peux rassurer, on a la même tendance !!!
Le PL/SQL a comme inspiration le langage ADA, qui a été développé pour l'Armée Américaine. Le but du langage est d'être "idiot prouve". Bref, avoir le moins d'erreur possible lors du développement d'une application et non de la coder rapidement.
Pour le Transact SQL, il n'a pas d'inspiration (pas à ma connaissance?) mais il me semble tout droit dérivé du Basic. Celui-ci est de permettre de programmer rapidement une application.
Deux philosophies très différentes. À l'image de leur SGBDR respectif, à quelques exceptions près il est possible techniquement de développer les mêmes application sur l'un ou l'autre mais dépendant de l'équipe TI, des besoins, de la philosophie de l'entreprise ou des moyens financier il sera plus avantageux de choisir l'un ou l'autre option.
Kognos
là je ne suis pas d'accord, en terme de fonctionnement ils sont très ressemblant.
c'est pas oracle avec red hat linux qui avait le record de transaction seconde il y a très peu?
perso dans les quelques entreprises où j'ai travaillé c'étais toujours oracle quand ça devait être utilisé dans des gros systèmes avec de gros volume de donnée
pour des systèmes de moins grande envergure c'étais ms sql server
et ça fait quelques boite que je vois qui migre de ms sql server vers mysql
oula de MS SQL server à MySQL
moi j'ai eu l'occasion de travaillé avec une base de données MySQL avec 3-4 grosses tables de 400 millions de lignes optimisés au maximum.
Je pense que MySQL s'en tire pas trop mal au niveau de la volumétrie ca serait pas contre plus
- au niveau fiabilité
- au niveau des fonctionnalités, MySQL vient juste de se reveiller avec les procédures.
Ce que je veux dire c'est que pour le moment Oracle et MS SQL serveur ne joue pas dans la meme cours que MySQL selon.
Apres si l'on a pas besoin de fonctions avancées, pourquoi pas en effet ...
LE CHOIX DES SGBD ENTRE SQL SERVEUR ET ORACLE
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,.......
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
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.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
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 +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Affirmation surprenante en regard de la croyance populaire et pas évidente à démontrer étant donné qu'Oracle se paie le luxe de pouvoir tourner sur d'autres OS que Windows...
En terme de réputation, Oracle reste leader lorsque l'on commence à parler de dizaines de millions de lignes, mais il est intéressant de voir des pro affirmer que SQL Server est devenu une alternative valable.
à la décharge d'Oracle, c'est évidemment plus facile d'assurer la sécurité lorsqu'on est éditeur de l'OS en plus du SGBD. Ca n'excuse pas les défauts d'Oracle (avec des bugs très connu qui datent d'Oracle... 7
Faut dire que c'est assez récent puisque, selon moi, SQL Server est vraiment devenu intéressant à partir de la version 2005. Et comme tu le dis, SQL Server souffre d'un gros handicap, il ne tourne que sous Windows et de fait limite le public visé, AIX ou HP-UX étant encore très présent notamment dans les grands comptes. Mais Windows est également un OS qui fait son chemin et avec le prix des machines vendues par HP et IBM pas mal de SI revoit leur politique pour passer à des machines moins onéreuses et migrer vers des machines virtuelles sous MS (la gamme pro de MS étant indéniablement de meilleur qualité depuis que Balmer est au commande). En attendant que Linux s'impose d'avantage à l'esprit des DSI ? A suivre...
J'ajouterai que si Oracle fait des efforts sur l'IHM, ça reste un SGBD considéré comme un SGBD compliqué à administrer donc couteux (avec en plus une politique tarif trop peu avantageuse)... alors que SQL Server a toujours fait l'unanimité coté interface et maintenant peut démontrer des compétences certaines même dans des environnements critiques. Tout cela faisant, il est assez difficile aujourd'hui de départager les deux. Maintenant que je connais SQL Server (je suis DBA Oracle à la base et je n'ai connu qu'Oracle depuis 10 ans) je suis bien obligé de constater que c'est un SGBD très intéressant et qu'Oracle d'un autre coté sort des versions toujours avec un rythme effréné (la 11g est déjà sortie alors qu'on commence à peine à profiter des atouts de la 10g
Evidemment, cela reste mon observation personnelle qui n'a pas valeur de vérité absolue
On peut toujours se consoler en disant que le couple Oracle/Linux propose le meilleur rapport prix/performance
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.
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
La norme est faites pas les éditeurs et Oracle, comme IBM y a participer depuis l'origine.C'est Oracle qui est "antinormatif" ou la norme qui est "anti oracle" ?
Le rapporteur de la norme SQL est depuis plus de 10 ans, M. Jim Melton... Qui est monsieur Jim Melton ??? Simplement le principal conseillé technique d'Oracle depuis de nombreuses années ! Stupéfiant non ???
Je vous met au défit de réaliser en une requête SQL sous Oracle l'exemple de parcours de graphe que je donne dans cet article : http://sqlpro.developpez.com/cours/s...te-recursives/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.
Recherche du plus court chemin dans un réseau routier...
Il le sont et l'apport d'Oracle sur ce sujet est indéniable, car parmi les rares points d'amélioration de ces fonctions dans la future version de la norme SQL:2008 il y a les fonctions LEAD, LAG, FISRT_VALUE, LAST_VALUE, NTH_VALUE... Lisez ce que j'ai écrit sur le sujet : http://sqlpro.developpez.com/SQL2008/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
Mais le CASE qui est la norme existe depuis 1986 dans DB2 et a été normalisé en 1992...C'est plus important, pour moi, d'avoir eu decode [...] depuis 87
Oui sauf que la fiabilité d'Oracle n'est plus ce qu'elle était ! Quand à la productivité on sait depuis longtemps que les coûts de développement sous Oracle sont biens plus élevés que sous SQL Server et c'est d'ailleurs la raisons majeure qui pousse bon nombre d'éditeurs et de grands centres informatique à quitter le monde Oracle pour aller vers le diable MS !...ce qui compte, amha, c'est fiabilité, productivité, performance.
Je suis en ce moment même en train de donner une formation admin SQL Server pour une des grandes entreprises du domaine pharmaceutique qui commence à investir massivement sur SQL Server au détriment d'Oracle...
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Une des évolutions est de permetre de traiter des connect by avec des tables en jointure. Vue l'algorithme utilisé, cela ne sert pas à grand chose quand on veux des temps de réponse raisonnable ! Connect by, ce n'est pas terrible, c'était simplement là tres tot et cela m'a rendu de sacré services, tout comme decode. Certe case, c'est mieux.
Je pense qu'avec les pipelines, on peut résoudre des problèmes difficilement gérable avec la norme.
Maintenant, que les 2 solutions se "tirent la bourre", cela me semble une bonne nouvelle pour nous.
Après, on peut toujours discuter de qui est le meilleurs, je pense que cela sera encore longtemps une question de gout, d'habitude et de chapelle.
Ouai mais avec Oracle j'ai les fonctions stat
ouai mais avec sql server, les requettes récursives
ouai mais avec Oracle les exceptions de PL
ouai mais avec sqlserver c'est Bill
Ouai mais avec oracle c'est Larry
etc...
L'interet de ce topic est de rester dans des partages d'experiences et des comparatifs de fonctionnalités.
un très gros avantage de oracle, c'est d'avoir le choix de l'os...
à l'heure où les migrations vers linux sont de plus en plus populaire.... c'est un critère non négligeable
Répondre avec citation
Partager