Discussion :

[scheu]

Postgresql est injustement méconnu et répandu dans le monde professionnel, alors qu'il est très bon (cf débat Mysql/Postgresql qui liste les avantages de Postgresql) .
Maintenant c'est vrai que ce topic parle d'Oracle. Je dirais brièvement pour Oracle :
AVANTAGES :
- optimiseur très évolué (se trompe rarement quand les stats sont à jour et que la requête est bien écrite, même pour des jointures complexes de plusieurs dizaines de tables)
- gestion de grosses volumétries
- beaucoup de fonctionnalités pour la haute dispo (dataguard, RAC, ...)

INCONVENIENTS :
- prix
- beaucoup de bugs, surtout quand on passe un patch qui corrige un bug mais qui en rajoute un nouveau ...

Concernant le débat sur les tarifs et le choix du SGBD des entreprises, je pense que le choix n'est pas que financier mais aussi politique :
- dépendance vis-à-vis d'Oracle si l'application est développée en en PL/SQL ?
- progiciels qui ne tournent qu'avec Oracle mais pas avec Postgresql, MySQL, ...
- support quasiment inexistant sur les SGBD open-source : risque à prendre ou pas ...

[ypicot]

Un des avantages d'Oracle est... que c'est Oracle.

J'ai proposé récemment une solution Sql Server + C# (donc le truc pas totalement exotique), et j'ai été proprement blackboulé parce que je "n'utilisais pas les standards" : Oracle + Java.

Pour certains clients, je sais que si j'implémente une solution Postgresql (pour ne citer que celui-là) et qu'il y a un loupé sur la BD (style temps de réponse trop long), on me dira "ouais, c'est normal, vous n'avez pas pris du standard"
Si j'implémente une solution Oracle et qu'il y a un loupé du même type, ca passera souvent avec un "bon, c'est un peu long, mais tant pis".

Pour Oracle, il y a une notion de parapluie, de protection très apprécié des DSI, mais également de tradition, de "on a toujours fait comme ça" et de "en principe, c'est le meilleur".

Ca n'entre pas dans un comparatif technique, mais je pense que ces deux arguments sont à prendre en compte.

Yvan

[saad.hessane]

Je plussoie. Bien que n'étant pas professionnel, je plussoie quand même.

[Antoun]

...
Pour Oracle, il y a une notion de parapluie, de protection très apprécié des DSI, mais également de tradition, de "on a toujours fait comme ça" et de "en principe, c'est le meilleur".

Ca n'entre pas dans un comparatif technique, mais je pense que ces deux arguments sont à prendre en compte.

Absolument, et je pense que ça répond à la soi-disant rationnalité des grosses DSI... Je dirais bien qu'Oracle est un standard alternatif, mais de fait, avec 50% du marché, c'est Oracle qui est le standard (horresco referens), et la norme SQL le standard alternatif.

[orafrance]

Certes, mais c'est quand même fâcheux de s'évertuer à aller contre la norme quand tous les autres acteurs du marché tendent vers celle-ci... d'autant plus quand on participe à son élaboration

[dingoth]

Pour moi, le principal désavantage d'Oracle est son système de versionnement incompréhensible :

(Pris de wikipédia)
Oracle 7 : 7.1, 7.2, 7.3
Oracle 8 : 8.0.3, 8.0.4, 8.0.5, 8.0.6
Oracle 8i : 8.1.5 (Release 1), 8.1.6 (Release 2), 8.1.7 (Release 3)
Oracle 9i : 9.0.1 (Release 1), 9.2.0 (Release 2)
Oracle 10g : 10.1 (Release 1), 10.2 (Release 2)
Oracle 11g : 11.1 (Release 1)

J'ai beau essayer, je ne comprends toujours pas la logique derrière : pourquoi sauter le 9.1 ? Pourquoi utiliser une lettre ? Bref, ça a beau être expliqué sur Wikipédia, c'est du n'importe quoi et ça rend vraiment confus les pauvres développeurs qui doivent trouver pourquoi l'erreur se produit sur un oracle 8, mais pas un 8i et ce genre de choses. Leurs noms marketing peut être utilisé, mais à des fins de debugging, dire 8.1.7 c'est pas la mort ? Tout le monde comprend au moins.

Après, j'entends souvent les gars du support dire qu'Oracle est un bouffeur de ressources phénoménal.

[orafrance]

i pour internet et g pour grid. Le i a été introduit avec Oracle 8, la 8i étant d'avantage orienté internet (notamment avec les packages java si je ne m'abuse).

Moi ce qui me gène plus c'est la constance d'Oracle à livrer une x.0 qui est systématiquement farci de bugs Je me souviendrais longtemps de DBCA qui était même incapable de créer une base lorsque la 10g est sortie

[Vincent Rogier]

Pour moi, le principal désavantage d'Oracle est son système de versionnement incompréhensible

Tous les logiciels ont plus ou moins un système de versionning qui leur est propre. Il suffit de renseigner chez l'éditeur en question...

Pour Oracle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
 
Example : Oracle 9.2.0.1.0
 
   Number     Significance
 
         9         Major database release number
         2         Database maintenance release number
         0         Application server release number
         1         Component specific release number
         0         Platform specific release number
 
 
Major Database Release Number 
 
        This is the most general identifier. It represents a major new edition (or version) of the software that contains significant new functionality.
 
Database Maintenance Release Number
 
        This digit represents a maintenance release level. Some new features may also be included.
 
Application Server Release Number
 
        This digit reflects the release level of the Oracle Application Server (Oracle AS).
 
Component Specific Release Number
 
        This digit identifies a release level specific to a component. Different components can have different numbers in this position depending upon, for example, component patch sets or interim releases.
 
Platform Specific Release Number
 
        This digit identifies a platform specific release. Usually this is a patch set. Where different platforms require the equivalent patch set, this digit will be the same across the effected platforms.

[scheu]

c'est Oracle qui est le standard (horresco referens), et la norme SQL le standard alternatif.

Ce sont surtout les développeurs et les éditeurs qui font le choix de faire du "compatible pour Oracle" et non pas du "compatible à la norme SQL".

Exemples parmi d'autres chez Oracle :

- "(+)" au lieu de "left outer join" dans les jointures externes, le (+) étant une syntaxe propre à Oracle
- autorisation de "= NULL" similaire à "IS NULL" (d'après la norme SQL : le NULL ne peut pas être comparé à quelque chose)
- assimilation NULL = chaîne de caractères vide, ce qui est aussi contraire à la norme SQL. Exemple pour un champ "deuxième prénom" : NULL n'est pas pareil que chaîne vide : savoir que quelqu'un n'a pas de deuxième prénom (chaîne vide), ce n'est pas fonctionnellement la même chose que de ne pas savoir s'il en a un ou pas (NULL pour valeur inconnue)

Bref tout ça pour dire que c'est comme ça qu'après on se retrouve hélas pieds et points liés à un éditeur sans pouvoir en changer facilement

La "norme" aujourd'hui, ce ne doit pas être Oracle même au vu de sa part de marché, c'est et ça a toujours été la norme SQL

La norme SQL, indépendante des SGBDs, devrait être la seule norme à respecter, ce qui n'est malheureusement aujourd'hui pas le cas et Oracle n'est pas l'un des SGBD qui respectent le plus la norme SQL au jour d'aujourd'hui ...

[Invité]

Pour moi, le principal désavantage d'Oracle est son système de versionnement incompréhensible

Si c'est là le plus grave problème que tu rencontres avec Oracle, tu es une personne heureuse !

[dingoth]

Bah, je suis un développeur. J'utilise les tables créées par d'autres. Il y a juste que c'est moi qu'on appelle quand "il y a un bug". Et dernièrement, j'ai passé 4 jours à trouver la solution d'un bug, liée tout simplement au versionnement foireux d'Oracle. Parce que pour les admins Oracle, c'était Java, pour les développeurs Java, c'était Oracle. Au final, c'était les deux : un connecteur Java-Oracle 9.2 utilisé avec une oracle 9. Ce bug a coûté la place de mon supérieur.

Si je n'ai que ça comme bug et que je peux me considérer comme une personne heureuse, c'est que je ne touche pas à Oracle si ce n'est pour y faire des requêtes standard (CRUD), c'est tout.

Mais maintenant que j'y pense, ma boîte n'utilise aucune fonctionnalité propre à Oracle qui n'est pas dans le standard SQL. J'avais essayé de porter, pour le fun, les schémas et le contenu sur un SGBD PostgreSQL, ça a fonctionné de manière impeccable à quelques modifications et optimisations près. J'ai pas fait les tests de charge (bien qu'actuellement, on tourne à 10-15 transactions / seconde), mais je ne comprends pas pourquoi nous avons besoin de cette usine à gaz pour l'utilisation que nous en faisons. Dans notre cas, on dépense donc une fortune en licenses Oracle (environs une quinzaine de processeurs) pour des choses qu'un système gratuit peut (à première vue) faire.

[jmguiche]

Ce sont surtout les développeurs et les éditeurs qui font le choix de faire du "compatible pour Oracle" et non pas du "compatible à la norme SQL".

Exemples parmi d'autres chez Oracle :

- "(+)" au lieu de "left outer join" dans les jointures externes, le (+) étant une syntaxe propre à Oracle
- autorisation de "= NULL" similaire à "IS NULL" (d'après la norme SQL : le NULL ne peut pas être comparé à quelque chose)
- assimilation NULL = chaîne de caractères vide, ce qui est aussi contraire à la norme SQL. Exemple pour un champ "deuxième prénom" : NULL n'est pas pareil que chaîne vide : savoir que quelqu'un n'a pas de deuxième prénom (chaîne vide), ce n'est pas fonctionnellement la même chose que de ne pas savoir s'il en a un ou pas (NULL pour valeur inconnue)

Bref tout ça pour dire que c'est comme ça qu'après on se retrouve hélas pieds et points liés à un éditeur sans pouvoir en changer facilement

La "norme" aujourd'hui, ce ne doit pas être Oracle même au vu de sa part de marché, c'est et ça a toujours été la norme SQL

La norme SQL, indépendante des SGBDs, devrait être la seule norme à respecter, ce qui n'est malheureusement aujourd'hui pas le cas et Oracle n'est pas l'un des SGBD qui respectent le plus la norme SQL au jour d'aujourd'hui ...

La jointure externe, (+) au lieu de left...

• Oracle propose la jointure externe depuis au moins 87, bien avant que la norme existe, et a la gentillesse d'assurer la compatibilité ascendente pour ses clients.
• Par ailleurs oracle support la bien trop verbeuse (amha) syntaxe de la norme avec left.

=NULL similaire à is null

• Tu es sur de ce que tu avance ? Si ce que tu dis est vrai, c'est vachement nouveau !

Assimilation de null à une chaine vide

• Même remarque que pour la jointure externe, si ce n'est que là, c'est vrai, Oracle ne supporte pas la norme.
• et en plus, dans les reflexions sur les acceptations de la signification de la valeur NULL, il y a toujours eu
  Je ne sais pas (null pour la norme)
  N'a vraiment pas de valeur (chaine vide pour la norme)
  Bien avant la norme, les théoriciens du relationnel amalgamaient les 2 "valeurs.
  Mais pas que ces 2 là, je me souvient d'une liste de plusieurs dizaine de sens différents ! Ce la va bien au delà de "n'a pas" et "n'existe pas".
  Différencier chaine vide de null, le point de vue de la norme, est un point de vue récent (et plutot inutile d'un point de vue opérationel d'aprés mon experience), tout cela fini entre les mains d'un utilisateur que va prendre les informaticiens pour des fous si on se lance dans ce genre de discours en le poussant trop loin. Pour lui "y'a rien dans la case et comme je n'ai rien à y mettre, j'y met rien".

[gregory.broissard]

- support quasiment inexistant sur les SGBD open-source : risque à prendre ou pas ...

Ca c'est extremement structurant parce qu'effectivement c'est un grand avantage d'Oracle et globalement des SGBDR payants par rapport aux autres : le support.

Et oui, quand j'ai un probleme sur une base de production importante, j'aime bien avoir une réponse en moins de 4h.

[scheu]

Ca c'est extremement structurant parce qu'effectivement c'est un grand avantage d'Oracle et globalement des SGBDR payants par rapport aux autres : le support.

Et oui, quand j'ai un probleme sur une base de production importante, j'aime bien avoir une réponse en moins de 4h.

Et encore ça dépend des fois j'attends une semaine pour avoir une réponse à un incident Oracle que j'ai ouvert ... Mais bon, il faut reconnaître que le support Oracle en ligne (Metalink) est une base très riche, on ne trouve pas un équivalent sur de l'open-source

[fatsora]

Et encore ça dépend des fois j'attends une semaine pour avoir une réponse à un incident Oracle que j'ai ouvert ... Mais bon, il faut reconnaître que le support Oracle en ligne (Metalink) est une base très riche, on ne trouve pas un équivalent sur de l'open-source

Heuresement que le support est la , car vu ce qu'on paie, ce n'est pas toujours
rapide les interventions meme qualifiés en 2 , 2 voire trois semaines d'intervention , des fois ils essaient juste de gagner du temps ....

Il y eu meme un momentet cela a duré tres longtemp ou la recherche sur metalink est tres aproximatif.

Aujourd'hui la nouvelle version est tres lent ....

[Vincent Rogier]

Heuresement que le support est la , car vu ce qu'on paie, ce n'est pas toujours
rapide les interventions meme qualifiés en 2 , 2 voire trois semaines d'intervention , des fois ils essaient juste de gagner du temps ....

Tout dépend du niveau de gravité du bug... et le système d'escalade et de hiérarchisation d'Oracle permet de séparer les bugs d'exploitation vitaux et bloquant des non bloquant.

J'ai déja ouvert des SR chez Oracle sur des bugs OCI... Qui ne bloquait en rien notre activité en exploitation ou en R&D... J'ai patienté 3 mois pour avoir une réponse disant que les bugs était corrigé pour la version suivante de Oracle....
Cela permet de gérer les priorité comme aux urgences. Si tous les petit bobos étaient traités de la même façon que les gros bobos, ca serait n'importe quoi...
Par contre, si j'ouvre un SR bloquant chez Oracle et demande l'escalade qui est validé par le support, la réactivité du support est alors très bonne !

[orafrance]

- autorisation de "= NULL" similaire à "IS NULL" (d'après la norme SQL : le NULL ne peut pas être comparé à quelque chose)

cette écriture n'est pas non plus autorisée par Oracle

[scheu]

cette écriture n'est pas non plus autorisée par Oracle

Apparemment si , par d'erreur Oracle quand on lance la requête suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT 1 FROM DUAL WHERE 1 = NULL

[Aquaa]

qu'est ce qui te fait dire ça ? Parce qu'au niveau des isolations des transactions, SQL Server est bien meilleur

tu as raison j'ai oublié de mentionner que c'est mon propre point de vu,en developpant mes aplications j'ai pas à me soussier des transactions etant donné que je développe en RAD(delphi).
Dans le cadre d’une transaction typique, Oracle placera un verrou sur la rangée en cours de modification, et ce verrou sera maintenu tant que cette transaction ne sera pas confirmée ou infirmée par les instructions « commit » ou « rollback ». Ce fonctionnement est adéquat dans la majorité des situations, où les transactions sont courtes ou encore lorsque les transactions concurrentes sont la plupart du temps indépendantes. Qu'en est-il des transactions qui peuvent durer des heures ou même parfois des jours à être complétées, et dont la durée va même au-delà des ouvertures et fermetures de banques ?
suite http://francais.directionsmag.com/ar...rticle_id=2907



Il est très difficile de faire la comparaison entre les performances de SQL Server et Oracle . Les performances de vos bases de données dépend plutôt de l'expérience des développeurs de bases de données et administrateur de base de données que de la base de données du fournisseur. Vous pouvez utiliser ces deux SGBDR pour faire stable et efficace. Toutefois,



un ptit comparatif

SQL Server
* moins cher d'acheter que de bases de données Oracle .
* tient le haut TPC-C de performance et de prix / performance des résultats.
* est généralement considéré comme plus facile à installer, utiliser et à gérer.

Oracle

* la Base de données Oracle tourne sur toutes les plates-formes connues.
* PL / SQL est plus puissant que le langage T-SQL.
* Plus de réglage fin à la configuration peut être fait par les start-up paramètre

[orafrance]

ha ok, pour les transactions longues en effet