Discussion :

[orafrance]

Moi aussi j'aime bien le PL/SQL

[ZashOne]

Moi aussi j'aime bien le PL/SQL

Idem , D'ailleurs je sais pas si ca existe dans les autres SGBB car j'ai pas eu besoin mais la fonction table(mafonction) meriterait le prix nobel de la sgbd

[fatsora]

Inconvénients

- Peu adapté aux petits projets

Tu as Standard Edition ou XE ...

- Modèle économique 'out of date'

Qu 'est ce que tu veux dire ???

- Support beaucoup plus onéreux que les autres

C'est une politique que l'on peut voir chez tous les N°1 de leur domaine,
mais ca n'excuse en rien les tarifs ...

Ceci dit as -ton vraiment comparé avec les tarifs d'IBM et ou Microsoft??
et voir ce qu'on a a ces prix la

- Nécessite un vrai dba full time, au minimum

bah , Administrer Cisco aussi , ou administrer Lotus Notes

des fois il ya meme une equipe d'administrateur de messagerie, ou d'administrateur de sauvegarde ...

Aujourd'hui il un a des offres d'emploi specifiant administrateur de base Mysql ou sqlserver ... alors qu'avant c'est fait par des admin system

- Très très long à maitriser

Ca va de soit,... comme c'est un produit tres souple ,pour maitriser les 100000 pages d'aide il faut plusieurs vies

[orafrance]

Aujourd'hui il un a des offres d'emploi specifiant administrateur de base Mysql ou sqlserver ... alors qu'avant c'est fait par des admin system

SQL Server reste beaucoup plus simple à administrer et requiert moins de compétence qu'Oracle... c'est moins amusant du coup

[B.AF]

- Support beaucoup plus onéreux que les autres

Par rapport au poids du support dans le coût de license par défaut (25% en moyenne) --> je parle du prix du soft, pas du coût dans la boite qui utilise Oracle.

- Peu adapté aux petits projets

XE ou Standard soit, mais ça reste du Oracle, et c'est une politique produit plutôt récente, là ou d'autres (postgre par ex.) on une expérience plus significative. Oracle n'a pas l'image d'un éditeur de bases tout usage, mais plutôt une image de SGBD haute disponibilité.

- Modèle économique 'out of date'
Ca reste de la vente de license, onéreuse. C'est un modèle qui devient compliqué (license, coûts de maintenance, formation, consulting).

- ADA et PL
C'est un avis personnel très subjectif je trouve ça rédhibitoire de se dire q'une grosse application repose sur une techno propriétaire, alors même que des standards éprouvés existent et qui joue autant sur le temps d'apprentissage.

[jmguiche]

C'est amusant qu'on dise qu'oracle est inadapté pour les petits projets, quand j'ai commencé à l'utiliser (1987) on avait droit à "Oracle ? C'est pas adapté aux gros projets !".

Je de demande bien à quel "petit projet" la version standard ou à XE, avec APEX qui plus est, n'est pas adapté. C'est quoi un petit projet ?

Quant à PL, je ne connais pas de language plus productif et plus performant pour mettre en oeuvre des règles de gestion sur une structure de données relationnelle. Et comme nos données sont stockées dans des structures relationnelles...

[Alain B.]

- ADA et PL
C'est un avis personnel très subjectif je trouve ça rédhibitoire de se dire q'une grosse application repose sur une techno propriétaire, alors même que des standards éprouvés existent et qui joue autant sur le temps d'apprentissage.

ADA ? Il y a un rapport ADA / Oracle ?

PS: on peut difficilement faire plus standard et éprouvé qu'ADA

[wizdom]

SQL Server reste beaucoup plus simple à administrer et requiert moins de compétence qu'Oracle...

Plutôt d'accord.

Mais c'est de moins en moins vrai avec les dernières versions d'Oracle où quasiment toutes les opérations peuvent s'effectuer en quelques clicks de souris via une console d'administration web (là où il fallait autrefois sortir les lignes de commandes à rallonge). La version XE est remarquable sur ce point : une installation ultra rapide (ce qui est rare chez Oracle) et une administration simplissime.

J'ai également des échos de certaines (grosses) boites où l'on n'hésite plus à dégraisser chez les DBA Oracle, là où ils y a quelques années ils étaient intouchables. Un signe ?

[orafrance]

Mais c'est de moins en moins vrai avec les dernières versions d'Oracle où quasiment toutes les opérations peuvent s'effectuer en quelques clicks de souris via une console d'administration web (là où il fallait autrefois sortir les lignes de commandes à rallonge).

Certes ça tend vers la simplicité, mais quand tu montes un mirroring en 3 minutes sous SQL Server faut compter de grosses gouttes de sueurs et quelques dizaines de cafés avec Dataguard

Déplacer une base de données idem, 3 minutes sous SQL Server, sous Oracle ça peut être vite pénible.

J'ai également des échos de certaines (grosses) boites où l'on n'hésite plus à dégraisser chez les DBA Oracle, là où ils y a quelques années ils étaient intouchables. Un signe ?

Bah le signe c'est que les boites commencent peut-être à comprendre qu'il y a pas mal d'incompétents en poste et qu'il faut peut-être refaire un tour du marché de temps en temps

[fatsora]

J'ai également des échos de certaines (grosses) boites où l'on n'hésite plus à dégraisser chez les DBA Oracle, là où ils y a quelques années ils étaient intouchables. Un signe ?

En interne les compétences compte jusqu'au n+1 apres c'est du relationnel ...

i.e il n'y a que le n+1 qui sait si t'estbon ou pas , au dessus c'est du relationnel

Alors le degraissage ....

Lors des premiers resultats négatifs , le directeur fiancier se sent obligé de demander de reduire les couts d'ou :
-incitation du personnel a partir de gré ou de force .
(sans remplacement des postes )
-externalisation

Conséquence au niveau des DSI : pas d'exception ,tous les services sont concernés , en premier lieu les projets sont arrétés (on dit poliment gelés ) migration, nouvelles versions... et en dernier c'est l'exploit .

A ce niveau-la (Exploitation) on sauve les meubles .... car il faut quand meme
faire tourner le maximum de services

Ceci dit, les profils les plus pointus , les plus facilement adaptables sont parmi les premiers a partir (se font chasser) donc ca aussi c'est a prendre en compte.

Donc parmi ceux qui restent , il y a encore pas mal d'incompétents mais qui savent bien faire des Powerpoint ou savent bien se faire voir aupres des bonnes personnes i.e ceux qui prennent des décisions (N+2,N+3 ....)

[ZashOne]

Voivi une petite histoire qui m a vraiment decu d 'oracle.

Je developpai le mois passé pour le travail une application en 64 bits sous windows server 2008 64 bits qu utilise intensivement ODBC pour acceder aux données.

L'application devait pouvoir tourner avec Mysql et oracle .

Durant le cycle de dev , je suis tombé sur un bug dans le driver ODBC de mysql et un bug (different) dans le driver odbc de oracle.

Pour Mysql, apres un peu de google , je me sus retrouvé sur le forum ou un post avait été ecrit a ce sujet et un patch avait été fourni . Il m'a suffit donc de telecharger la version snapshot - beta du driver et le problème etait resolu.

Pour oracle , j'ai posté un service request metalink.
Il a fallu deux semaines aux technicien pour identifier le problème.

(A la fin ca devenait ridicule , je lui envoyé un exemple , il me repondait qu'il ne trouvait pas le problème , je lui demandait si il etait bien en 64 bits , il me disait qu il s'excusait mais qu il etait en 32, ensuite il me di qu'il n 'arrive pas a compiler en 64 bits , j 'ai du lui expliquer qu'il lui fallait le compilateur 64 bits ....)

Pour finir , j'ai vu qu 'il y avait un patch qui semblait repondre a mes besoins dans une version anterieure a la mienne. Le technicien a donc testé sue les deux versions et a demander de faire une BACKPORT du patch. D'apres lui le temps d'attente pour recevoir le patch est de 6 a 8 semaines.
J ' en suis a la deuxieme semaine d'attente sans compter les deux premieres .................

[Vincent Rogier]

Voivi une petite histoire qui m a vraiment decu d 'oracle.

Je developpai le mois passé pour le travail une application en 64 bits sous windows server 2008 64 bits qu utilise intensivement ODBC pour acceder aux données.

L'application devait pouvoir tourner avec Mysql et oracle .

Durant le cycle de dev , je suis tombé sur un bug dans le driver ODBC de mysql et un bug (different) dans le driver odbc de oracle.

Pour Mysql, apres un peu de google , je me sus retrouvé sur le forum ou un post avait été ecrit a ce sujet et un patch avait été fourni . Il m'a suffit donc de telecharger la version snapshot - beta du driver et le problème etait resolu.

Pour oracle , j'ai posté un service request metalink.
Il a fallu deux semaines aux technicien pour identifier le problème.

(A la fin ca devenait ridicule , je lui envoyé un exemple , il me repondait qu'il ne trouvait pas le problème , je lui demandait si il etait bien en 64 bits , il me disait qu il s'excusait mais qu il etait en 32, ensuite il me di qu'il n 'arrive pas a compiler en 64 bits , j 'ai du lui expliquer qu'il lui fallait le compilateur 64 bits ....)

Pour finir , j'ai vu qu 'il y avait un patch qui semblait repondre a mes besoins dans une version anterieure a la mienne. Le technicien a donc testé sue les deux versions et a demander de faire une BACKPORT du patch. D'apres lui le temps d'attente pour recevoir le patch est de 6 a 8 semaines.
J ' en suis a la deuxieme semaine d'attente sans compter les deux premieres .................

Voila ce qui arrive quand on veut bosser avec ODBC

[voran]

Voivi une petite histoire qui m a vraiment decu d 'oracle.
....
Pour finir , j'ai vu qu 'il y avait un patch qui semblait repondre a mes besoins dans une version anterieure a la mienne. Le technicien a donc testé sue les deux versions et a demander de faire une BACKPORT du patch. D'apres lui le temps d'attente pour recevoir le patch est de 6 a 8 semaines.
J ' en suis a la deuxieme semaine d'attente sans compter les deux premieres .................

Bizarre, je n'ai jamais eu à me plaindre des ingénieurs support de chez ORACLE. Pas plus qu'avec ceux de MySQL et Microsoft en tout cas.

(A la fin ca devenait ridicule , je lui envoyé un exemple , il me repondait qu'il ne trouvait pas le problème , je lui demandait si il etait bien en 64 bits , il me disait qu il s'excusait mais qu il etait en 32, ensuite il me di qu'il n 'arrive pas a compiler en 64 bits , j 'ai du lui expliquer qu'il lui fallait le compilateur 64 bits ....)

Compiler quoi sur windows, ton application ?

J'ai eu une très mauvaise expérience du portage de notre application, qui tourne depuis des lustres sur UNIX/LINUX 64bit, sur windows 2003 x64.
On sent que le passage de w2k3 en architecture 64bit s'est fait dans la douleur.

[voran]

Bah le signe c'est que les boites commencent peut-être à comprendre qu'il y a pas mal d'incompétents en poste et qu'il faut peut-être refaire un tour du marché de temps en temps

Comme dans tous les domaines

[ZashOne]

Bizarre, je n'ai jamais eu à me plaindre des ingénieurs support de chez ORACLE. Pas plus qu'avec ceux de MySQL et Microsoft en tout cas.

non moi non plus ; mais il y a d apres cette experience une grosse difference entre une sr oracle attribuée a la "perf team" et une sr oracle attribuée a la "ODBC Team" qui doit etre plus petite et moins organisée

Compiler quoi sur windows, ton application ?

non un test case de 20 lignes qui reproduisait le probleme

[Garuda]

Moi aussi j'aime bien le PL/SQL

Et moi , je l'adore
Et l'aspect "Tout beau, tout nouveau" des langages dit "modernes" (java, php) n'est pas forcément gage de robustesse, d'efficacité et de maintenabilité (ca c'est pour le mot "vieillerie")

[voran]

Tu veux dire implicitement ?
pourquoi ? Le grid control ça sent le camebert ?

Non, mais c'est aussi bien que cher... c'est dire comme c'est bien

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

[voran]

En effet, en fait je me suis arrêté à la page de Oracle Store qui l'indique en option pour la version Entreprise En fait, c'est en option pour l'entreprise mais inclus en standard... je ne vais pas essayer de comprendre :mouarf

En fait, une petite précision :
ORACLE RAC (2 noeuds maxi) est compris dans la licence standard Edition à condition d'utiliser ASM.
Le but était de favoriser l'utilisation d'ASM. Je viens d'avoir l'info d'un employé ORACLE aujourd'hui.

[SQLpro]

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
...

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/).

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...).

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...

Or c'est le contraire chez IBM DB2, SQL Server et PostGreSQL qui essayent de respecter le plus possible les normes SQL. Car contrairement à ce que beaucoup pensent, les normes sont très intelligentes. N'oublions pas qu'elles sont faites par les éditeurs eux mêmes et que le rapporteur de la norme, Jim Melton est paradoxalement le principal conseiller technique d'Oracle. Preuve que les cordonniers sont souvent mal chaussé.

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é. En effet la fiabilité de SQL Server sur plateforme Windows est actuellement considérée comme supérieure aux divers Linux et Unix. 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 !).

Le second point négatif est donc la sécurité et la correction des bugs qui est particulièrement pénalisante.

Enfin le dernier point est le coût d'Oracle à tous les niveaux. Les ressources serveurs nécessaires aux instances Oracle sont très gourmandes et souvent de façon injustifiées. 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.

Enfin la complexité du couple JEE / Oracle en matière de développement Web, mesuré dans différents projets dans les années 90/2000 à montré une différence de l'ordre de 50% (et oui, c'est pas rien...) qui a toujours cours ici en comparaison à la cohérence de la plateforme .net / SQL Server.
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. 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 ?

A +

[Fabien Celaia]

Bon ! en préambule, je suis à peu près kif-kif sur Oracle et MS-SQL, donc je me permets qq commentaires...

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/).

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

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...).

Pourquoi ne passent-il pas à l'unicode?

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...

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...

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é. En effet la fiabilité de SQL Server sur plateforme Windows est actuellement considérée comme supérieure aux divers Linux et Unix. 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 !).

Le second point négatif est donc la sécurité et la correction des bugs qui est particulièrement pénalisante.

Sur la sécurité, rien à redire : Oracle, c'est une passoire !
Sur les bugs, ils sont proportionnels à la richesse fonctionnelle, et architecturalement parlant, Oracle a le poid des ans à porter...

Enfin le dernier point est le coût d'Oracle à tous les niveaux. Les ressources serveurs nécessaires aux instances Oracle sont très gourmandes et souvent de façon injustifiées. 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.

Enfin la complexité du couple JEE / Oracle en matière de développement Web, mesuré dans différents projets dans les années 90/2000 à montré une différence de l'ordre de 50% (et oui, c'est pas rien...) qui a toujours cours ici en comparaison à la cohérence de la plateforme .net / SQL Server.
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. 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 ?

A +

Pour les ressources matérielles nécessaires, pas de discussion là dessus : c'est à mon avis parfaitement exact.

Pour la robustesse Windows/Unix, je laisse là la guerre des clans s'étendre... quant à moi, 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.

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... Comparaison n'est pas raison... La richesse et la complexité génère forcément des soucis...