- Postgresql est rapide (depuis la 8.2 surtout)
- Postgresql permet l'écriture de procédures stockées en une grande variété de langages (python, java, ruby, c, tcl, etc...) (contrairement a Oracle)
- Postgresql peut se ballader sans un serveur d'application qui va pomper 50% de la memoire pour être utilisé une fois toute les 2 semaines (contrairement a Oracle)
- Postgresql est entièrement modulaire (contrairement a Oracle)
- Postgresql est disponible plus frequement sur les hébergement mutualisé, et est plus simple a installer qu'oracle sous linux et dérivé (apt-get install postgresql-server)(sous windows je sait pas)
- Postgresql essais va pas aller utiliser un "pseudo-sql modifié" (contrairement a Oracle)
- Postgresql est simple a administrer (1 fichier pour la config interne, 1 fichier pour les autorisations sur les interfaces réseau, un ptit combo ANALYZE/VACUUM/REINDEX en cas de besoin (1x par semaine max je dirais, et Hop c'est fini)
et surtout:
Postgresql est gratuit, et oui, le développeur ou l'entreprise a pas envie d'aller dépenser plus de 10k$ pour avoir un truc a moitié bugué comme Oracle, et qui va lui meme demander un serveur de plus de 15k$ pour tourner convenablement, alors qu'on peut avoir la même chose sans rien payer, totalement stable, et qui arrive a booter sur un P3 avec 256mo de ram sans broncher...
Bref, Postgresql n'a strictement rien a envier a Oracle, ça serais plutôt l'inverse je pense... ou est l'interet d'utiliser Oracle ?
Bon, tu peux me dire alors pourquoi Oracle détient 48% du marché DB global et 88% sous linux ?
Sûrement parce que toute les banques, les grand comptes, etc... sont tous des masochistes qui passent leur temps à dilapider leur pognon pour rien et choisissent Oracle car c'est le SGBD le plus pourri
Trêve de plaisanterie...Qui a dit que Postgre n'était pas un très bon sgbd ? Personne ici....
Maintenant, si tu veux uniquement parler de postgres, tu peux toujours aller dans le forum postgres !
Bien sur que Postgre est très rapide ! qui a dit le contraire ?
Pourtant oracle supporte aussi plein de langages...
Peut être pas ruby, certes, mais quel est intérêt de faire une procédure stockée en ruby si ce n'est plomber les perfs de ta base ?
Primo, la charge mémoire d'Oracle se paramètre comme on le désire.
Deuxio, que vient faire le serveur d'application dans l'histoire ?
Oui est alors... Mon canapé est rouge.
Surement... Oracle n'est pas destiné à servir de DB d'hébergement. Le meilleur choix pour l'hébergement reste MySql...
Encore une fois, tu te trompe de problématique
Oracle a été le premier SGBD certifié conforme ANSI SQL. Cela ne l'empêche d'avoir ses propres extensions comme tous les autres SGBD
Très bien... C'est un bon point pour postgre... Par contre la relative complexite d'administration d'Oracle peut être parfois pénalisante mais aussi très souvent une arme pour optimiser, tuner une instance en fonction de la machine, du profil de DB, de la charge, ...
et surtout:
Oui... mais encore une fois le monde doit vraiment tourner à l'envers puisque postgre est quasi invisible dans le monde professionnel (bancaire, industrie, marketing, collectivités, ....)
Les technologies de backends sont pas censé être visible a ce que je sache (puis bon si tout le monde utilisait ce qui est le plus utilisé, tout le monde ferais ses sites en php/mysql et coderais en C, buerk ;d )
si non quand je parle de serveur d'application, je sait pas vous, mais moi avec Oracle, j'ai toujours une interface web assez lourde pour créer des "applications" oracle et gérée quelques trucs
postgresql a aussi énormément de paramètres configurable (par exemple les procedures d'optimisation des requêtes, je peut définir un "poid" ou désactiver complètement une méthode (par exemple le scan séquentiel des tables), mais optionnels
puis bon ce que je veut dire, par exemple tu dit que pour l'hébergement, oracle c'est pas ce qu'il faut, donc on peut dire que postgresql est plus polyvalent dans les possibilités d'hébergement (pour le web c'est le top... bien mieux que mysql je trouve (plus complet, recherche fulltext au top, et meilleure concurrence, meilleur scalling, écriture de procédures puissances pour eviter les échanges de données superflus), personnellement j'utilise plus que ca
Ca fait cher de la baguette
-----
Pour l'instant j'utilise MySQL avec INNODB because it's free. Supposons que j'ai quelques centaines de k€ dans mon compte en banque et que je puisse donc dépenser quelques milliers d'euros pour trois clusters Oracle.
Pour gagner le plus d'argent dans mon modèle, il faut que le coût de la connexion par élève soit très faible (un peu comme Facebook : si ca leur coûte 10c par connexion, ils vont pas vivre longtemps).
Dans ces coûts, il y a la JVM, la connexion http entre serveurs java (SOA) et la connexion vers la database.
Enfin il y a aussi les coûts d'apprentissage pour qu'un employé (je suis riche, j'ai des employés ) sache gérer Oracle.
Est-ce qu'on peut me convaincre que passer de MySQL à Oracle me fait gagner des soux ? Par exemple, je peux tellement 'tuner' la db que les performances vont être de 20% supérieur à INNODB.
La seule fois où j'ai eu affaire à Oracle, c'était avec Java Server Face et ADF, et bon... c'est gratuit, mais c'est pas trop leur métier
Les prises de decisons en informatique ne sont plus uniquement que technique, la partie financiere est tres importante et souvent prime surtout le reste ,dans les PME , et meme dans les grands groupes.
N'oublions pas qu'en France il y a plus de PME que de grandes banques avec de gros projets internationaux impliquant des centaines voire plus en consutants/informaticiens !
D'ou ces migrations de Oracle vers Postgres , installation Oracle Standard Edition voir XE en production !
croyez moi, les directeurs fianciers et les services achats regardent bien du mauvais oeil ces prix de license Entreprise et ils ont souvent le dernier mot.
Les rubriques PosGreSql et Mysql de developpez.com peuvent aussi ouvrir des débats sur leurs avantages / inconvénients...
Merci de ne pas polluer ce débat en postant des topic ne parlant que d'autres SGDB...
On est la avant tout pour parler d'Oracle !!
Merci.
Sauf que parler des avantages et des inconvénients doit forcement être relatif a autre chose...
oui mais faire un post qui ne parle que postgre et ne fais que l'apologie de postgre n'est pas un post qui apporte beaucoup au débat...
Tu peux dire "Oracle fais pas ca" ou" Oracle est ceci"... Ca ok !..
Mais ton post était plus de la réclame pour Posgre qu'une analyse des avantages / inconvénient d'Oracle.
Oublions les perf... Il n'est pas possible d'annoncer quoi que ce soit comme ça. (encore que...)
Comment as tu développé ? Php? Java ? Avec peu de choses dans le sgbd a part les données ? Toutes les règles de gestion en java ?
Si il y a un développement conséquent pour ton projet, avec une approche thick DB, beaucoup de PL, peu de choses en java, voire pas de java du tout et un dev en Application Express, la facture globale pour ton client aurai probablement moindre et son time to market plus court.
Oracle permet un développement plus court que les architectures plus "à la mode". Cela permet, entre autre, un cout globale de projet bien moindre que ce que croient les tenant du "gratuit". Cela permet aussi un "time to market" bien plus court : le chemin critique, en informatique "sur mesure" passe par le développement, moins il y en a, mieux on se porte !
Encore un fois dire que SqlServer ou Oracle sont bien meilleur que l'un ou l'autre sans rien avancer pour étayer ne sert à rien !
De plus, chacun peut comparer son expérience de son SGBD à un autre sans pour autant avancer des propos objectifs. Cela ne sert à rien de comparer un SqlServer 2005 à un Oracle 7 ou un Oracle 11g à un SqlServer 7 ...
Donc, s'il vous plait, lancer de telles remarques est tout sauf constructif !
Par exemple, un avantage vérifiable et étayable d'Oracle est sa disponibilité sur plein de plateformes différentes avec un support associé de qualité. Quasiment aucun autre SGBD n'est disponible avec un tel niveau de support sur autant de plateformes. Ca c'est un fait !
SqlServer étant disponible sur une seule plateforme, sur ce point il est hors course...
Bien sur, d'autre SGBD sont aussi multi-plateformes, Oracle n'est pas le seul. Mais pas avec un support commercial assuré de la qualité de celui d'Oracle.
Un autre avantage, encore une fois objectif, est le PL/SQL. Peu de SGBD sont capables de fournir un langage procédural serveur aussi puissant riche et bien fourni que Oracle.
Posgre fait pas mal mais est toujours à la traine sur ce point (car son PL est fortement basé sur celui d'Oracle). Et la encore une fois, le T-SQL de SqlServer ne peut pas soutenir la comparaison (encore une fois, je me base sur les spécifications de ces 2 langages).
Un inconvénient d'Oracle Database est par contre, est son manque de support pour les OS embarqué et mobile... Oracle a bien racheté des outils comme Berkeley DB, mais par exemple, aucune support natif pour Windows CE autre que en .NET pour accéder à une base Oracle.
Le but de ce débat n'est pas de dire que Oracle est meilleur que les autres et que les autres sont pourris ou vice versa.
Le but de cette discussion est parler des avantages et des inconvénients du SGBD Oracle le plus objectivement possible et en appuyant les déclaration de faits, études, ou exemples.
Je rappelle que dire qu'un SGBD est meilleur qu'un que les autres n'a strictement aucun sens. Chaque SGBD a des points forts et des points faibles qui détermine son utilisation, sa diffusion et son exploitation dans les niches et domaines qui lui correspondent !
MySql a beaucoup de points forts tout comme SqlServer et les autres. Même MS Access est un très bon produit... pour l'utilisation pour laquelle il a été conçu.
Donc, Messieurs, s'il vous plait, un peu de sérieux et faites avancer le débat de manière constructive !
Merci
Il est vrai que SQL Server a plus de niveaux d'isolations de transactions qu'Oracle et que SQL Server respecte plus la norme ANSI qu'Oracle qui n'en supporte que 2 (READ COMMITTED et SERIALIZABLE). Cet article d'Oracle Magazine montre cependant que le standard SQL ANSI ne dit pas tout:
SQL Server 2008 (et non 2005) a enfin un niveau d'isolation (SNAPSHOT) similiaire au READ COMMITTED Oracle qui n'a pas besoin de prendre un verrou pour faire une simple lecture.The lesson here is that various databases executing in the same, apparently safe isolation level can and will return very different answers under the same circumstances. It's important to understand that, in Oracle Database, nonblocking reads are not had at the expense of correct answers. You can have your cake and eat it too, sometimes.
Enfin un post cohérent, objectif et documenté avec infos de version
Merci Pifor
Petite précision. Oracle effectivement ne gère que 2 des 4 niveaux d'isolation du standard. Mais il propose un 3eme niveau propre à Oracle : READ ONLY.
In addition to the four defined SQL isolation levels, Oracle Database provides another level: READ ONLY. A READ ONLY transaction is equivalent to a REPEATABLE READ or SERIALIZABLE transaction that cannot perform any modifications in SQL. A transaction using a READ ONLY isolation level sees only those changes that were committed at the time the transaction began. Inserts, updates, and deletes aren't permitted in this mode (other sessions may update data, but not the READ ONLY transaction). Using this mode, you can achieve REPEATABLE READ and SERIALIZABLE levels of isolation.
voir ici des listes tres detailles sur différentes bases
http://fadace.developpez.com/sgbdcmp/
en plus ca existait deja sur ce site ....
Je te remercie de ton lien... Mais je te rassure, ce comparatif est connu car écris par un des membre de l'équipe DVP...
Mais c lien est un comparatif pas un débat...
Bien que ce comparatif généraliste est l'issu d'une personne de qualité (notre responsable SqlServer), on peut ne pas être d'accord sur tout les caractéristiques avancées : certains points ne sont pas cités ou omis en fonction des SGBD, non documentés/arbitraires ou sont subjectifs. De plus, les qualités d'un SGBD peuvent varier beaucoup en fonction des versions...
De plus, s'attaquant à tous les SGDB, il ne peut être très exhaustif !
D'où l'intérêt de cette discussion !
Oui mais je dirais
-il apporte des éléments intéressants pour la question pricipale qui est avantages et incovenients Oracle en regardant que cette section dans la page
et en 2e
voir les autres SGBD pour ceux qui ne les connaissent pas
non ?
Le but c'est peut etre d'apporter des reponses succintes et non d'aller dans des details qui n'interessent pas forcement les non informaticiens ou les décideurs qui sont en entrepriseou client final directeur financier ou responsable d'achat ou meme directeur IT.
C'est fort pour quelqu'un qui à commencer par un troll sans analyse, sur le sujet :
;-)Quelques avantages (ce qui me vient en premier à l'esprit) :
* SGBD le plus portable (machines/architectures)
(...)
* Pas mauvais sur le marché de la haute dispo, gestion des clusters, ..
pas mal aussi celle làon, tu peux me dire alors pourquoi Oracle détient 48% du marché DB global et 88% sous linux ?
Sûrement parce que toute les banques, les grand comptes, etc... sont tous des masochistes qui passent leur temps à dilapider leur pognon pour rien et choisissent Oracle car c'est le SGBD le plus pourri
Bon je charri, je sais, mais la problématique n'est pas totalement là, à mon avis.
Les projets OpenSources souffres globalement d'un manque de support et d'une méconnaissance des décideurs. C'est normale, la publicité est plus faible et certains décideurs sont d'ancien tech. Ils utilisent donc les produits qu'ils connaissent et savent donc ou ils vont. Gage de qualité et de la réussite d'un projet.
Cette intro à forme de réponse/troll est là pour montrer certains des gros avantages, pour moi, d'Oracle sur ses concurrents. Ces avantages n'ont rien de technique pure :
- Plus facile de trouver des dbas en prestation ou en fixe
- Support important
- Compétence reconnu des dbas (en général ...)
Mais là encore, ces avantages ne valent que pour les gros projets (car chers).
Dans dans ton mémoire, tu peux parler des avantages technique et des avantages humains. Les 2 sont nécessaire à la réussite d'un projet.
Un inconvenient d'Oracle. La facturation au processeur. De ce fait, soit on investit dans une autre machine soit on paye cher la licence Oracle. Rajouter une machine n'est pas simplement un P3 et ses 256mo de ram sur une LFS(joke).
La facturation au cpu, est un pb grandissant avec les cpu multicores.
Bon cette info n'est pas de la toute dernière fraicheur, et il est possible que cela ait changé dernièrement. Mais doit rester vrai avec les anciennes versions d'Oracle. Il ne faut pas non plus perdre de vue, que dans une entreprise on a souvent d'anciennes version d'oracle que l'on fait évoluer en fonction de la fin du support de ces anciennes versions.
D'ailleurs ça me fait penser à une chose : que vaut la compatibilité ascendante des différentes versions d'Oracle ? Est-ce tres délicat de faire des upgrades de version ?
Partager