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