MySQL a vu sa popularité augmenter considérablement ces dernières années, et ce succès n'est pas prêt de s'arrêter. En effet, les versions de la branche 5 contiennent des améliorations attendues par les utilisateurs depuis de nombreux mois, voire années. Ainsi, certaines d'entres elles comme les vues, les triggers ou les procédures stockées vont permettre à MySQL de rivaliser pleinement avec les ténors commerciaux de la base de données tel qu'Oracle.
MySQL n'était déjà pas en retrait avec sa branche 4.1 dont le principal ajout était de permettre l'exécution de requêtes imbriquées. De plus, son extrême rapidité, sa facilité d'utilisation et de déploiement, ses nombreux formats de stockage, ou encore la multitude d'APIs disponibles pour de nombreux langages en ont toujours fait un serveur de bases de données très prisé. Mais avec la branche qui va sortir voici ce que vous allez être en mesure d'utiliser :
- Deux nouveaux formats de tables : ARCHIVE et FEDERATE. Le premier (déjà présent dans la version 4.1.3) permet le stockage de grandes quantités de données sans utiliser d'index et avec une empreinte mémoire de petite taille. Ce format utilise la zlib pour la compression des données. Le second permet d'utiliser les tables de bases de données se trouvant sur un serveur distant.
- Les procédures stockées. C'est l'un des atouts majeurs de la version, attendu par les utilisateurs depuis de nombreux mois.
- Les Triggers. Encore un des atouts qui va permettre à MySQL de se hisser à la hauteur d'Oracle.
- Les Vues (Views)
Et ce n'est évidemment qu'une petite partie des nombreux changements qu'apportera cette branche, que MySQL AB estime déjà très stable. La société appelle d'ailleurs les utilisateurs de sa BDD à tester massivement cette nouvelle mouture. Pour les encourager, elle offrira des iPod ou des passes pour la conférence MySQL Users 2006 à ceux qui feront les retours d'expériences et rapports de bugs les plus pertinents. Parmi les autres nouveautés, on compte :
- Un nouveau type de données BIT, pour stocker des nombres en notation binaire ;
- Un support basique des curseurs ;
- L'ajout d'une base "Dictionnaire des données" ou "Schéma d'Information" (INFORMATION_SCHEMA), qui fournie un moyen standard pour accéder aux métadonnées des bases ;
- L'introduction d'un gestionnaire d'instances utilisable pour contrôler l'arrêt et le démarrage d'un serveur, y compris à distance ;
- L'introduction de critères plus stricts pour la validation des données, et l'ajout d'une bibliothèque de calcul en virgule fixe pour des opérations arithmétiques plus précises ;
- L'ajout d'un mode serveur strict, respectueux du SQL standard, et le support des messages d'erreur standard SQLSTATE ;
- Un changement du type VARCHAR, qui supporte maintenant jusqu'à 65532 octets, et dont les caractères blancs en fin de chaîne ne sont plus éliminés ;
- Le support des transactions XA.
Aller plus loin
- MySQL (3 clics)
- Changements de la version 5 (5 clics)
- Communiqué Mysql AB (3 clics)
# PG
Posté par Pierre Tramo (site web personnel) . Évalué à 10.
[^] # Re: PG
Posté par Fanf (site web personnel) . Évalué à 10.
Sous la tournure trollesque du message, on peut voir de vraies questions, dont la principale est : quelles sont les différences majeures, en terme de fonctionnalité ou d'efficacité, entre la future monture de MySQL et la version 8 de la très bonne base Postgres ?
Bon, et pour éviter d'exploser tous les trollomètres neufs qui trainent (apparemment, la durée de vie de ses petits outils est très courte en ce moment...), on essaiera d'aborder le sujet des licences avec un certain détachement ;)
[^] # Re: PG
Posté par Jean-Max Reymond (site web personnel) . Évalué à 8.
Au hasard, support multi-langages pour les procédures stockées comme perl, java, etc
Le seul point sur lequel mysql a une petite avance est le clustering/replication mais c'est plutôt par défaut car Postgres ne se focalise pas sur ces points et ce sont des projets externes comme l'excellent Slony2 qui font avancer le schmilblik
[^] # Re: PG
Posté par gaetanpat . Évalué à 5.
[^] # Re: PG
Posté par BAud (site web personnel) . Évalué à 5.
- nerim pour tes pages perso cf. https://linuxfr.org/comments/627920.htm(...)
- http://tuxfamily.org(...) pour tes projets libres
- http://lost-oasis.fr/lo/mutu(...) pour tes sites sur un mutualisé
[^] # Re: PG
Posté par Ngoc-Khoi TO . Évalué à 1.
[^] # Re: PG
Posté par Ngoc-Khoi TO . Évalué à 2.
[^] # Re: PG
Posté par Sylvain Sauvage . Évalué à 2.
¹ : Remarquons que j'y arrive bien (en tout cas, ça fonctionne dans le « Vérifier »)...
# Tant mieux....
Posté par Gyro Gearllose . Évalué à 10.
Non pas que je mette en doute la qualité du travail fournie par toute cette équipe (faudrait être sacrément imbu de sa personne quand même). Je trouve simplement que c'est dommage, car postgreSQL est bien plus avancé que Mysql, et une alliance dès le départ aurait été bien plus bénéfique à tous.
D'ailleurs, la version 8.1 beta2 de postgreSQL est sortie le 18/09/2005, on n'en a pas fait grand bruit, pas même un pauvre journal, et je trouve ça bien dommage.
Tout ce qui est dit dans cette news, à propos des nouvelles fonctionnalités de Mysql est très prometteur, mais très tardif... PostgreSQL supporte tout ça depuis bien longtemps, et même beaucoup plus.
Enfin, au final, l'un convergeant vers l'autre à plus ou moins vive allure, on finira par avoir le choix entre deux logiciels qui proposent exactement les mêmes fonctionnalités. Je trouve que c'est gacher, mais ça reste mon avis.
Enfin, bravo à l'équipe de dev, quand même, car ré-inventer la roue depuis zero pour en arriver là, c'est un bien bel effort.
[^] # Re: Tant mieux....
Posté par blobmaster . Évalué à 9.
L'informatique *peut* rendre l'information automatique, encore faut-il être réceptif à cette information. Si on attend quelle vienne à nous (en moulant sur Linuxfr) on se retrouve avec des journaux fonctions du Buzz et des lecteurs qui disent :"On n'a pas parler de ça, linuxfr c'était mieux a vent!".
http://www.postgresql.org(...)
possède des flux RSS si tu veux que l'on en parle sur DLFP, alors il ne te reste qu'a rester connecté. C'est simple, l'information peut être automatique.
Cela dit, il existe
http://monstera.man.poznan.pl/wiki/index.php/Mysql_vs_postgres(...)
Et là tu te rends compte que si les deux projets sont deux projets (???), c'est peut-être que les objectifs (au moins a court termes) sont différents.
Ton histoire de développement commun c'est limite troll KDEvsGNOME.
[^] # Re: Tant mieux....
Posté par Anonyme . Évalué à 9.
Parce que les 3/4 des applications web font peu de requêtes compliquées mais, par le nombre d'accès aux pages, font nécessairement beaucoup de requêtes.
Et comme le fait que PostgreSQL soit plus lent que MySQL pour un certain nombre de requêtes simples n'a jamais été démenti, il s'avère que MySQL à du succès.
Et pour saisir cela, il est inutile de recourir à de la psychologie de bazar et présenter PostgreSQL comme un génie incompris.
[^] # Re: Tant mieux....
Posté par golum . Évalué à 1.
Non !linuxfr c'etait mieux à eau, comme les moulins
=========>[ ]
[^] # Re: Tant mieux.... mais ...
Posté par Manuel Da SILVA . Évalué à 2.
[^] # Re: Tant mieux.... mais ...
Posté par blobmaster . Évalué à 5.
Lighthttp Ada MicroBSD Postgresql
http://lighttpd.net/(...)
http://adaworld.com/(...)
http://www.microbsd.net/(...)
http://www.postgresql.org(...)
Et hop !
[^] # Re: Tant mieux....
Posté par Jérôme Pinot (site web personnel) . Évalué à 7.
Comme Firefox/Konqueror ?
Gnome/KDE/XFCE ?
<INSERT_OTHER_TROLL>
Et puis ce n'est pas tout a fait la meme chose d'ailleurs :
http://monstera.man.poznan.pl/wiki/index.php/Mysql_vs_postgres#MySQ(...)
Le fait d'avoir le choix n'est pas a critiquer. Si des devs ont voulu passer du temps a refaire certaines choses, ca les regarde et ca peut meme avoir des effets positifs pour l'utilisateur. Par exemple, PostgreSQL est bien plus fourni, mais MySQL est pour l'instant beaucoup plus rapide sur les tables MyISAM.
Et bien entendu, je ne parle pas des licences...
[^] # Re: Tant mieux....
Posté par Jean-Max Reymond (site web personnel) . Évalué à 8.
[^] # Re: Tant mieux....
Posté par jmny . Évalué à 2.
[^] # Re: Tant mieux....
Posté par Jean-Max Reymond (site web personnel) . Évalué à 3.
tu n'as plus ton goulot d'étranglement sur la maj de tes tables mais c'est toute la base qui semble prendre un très net ralentissement.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tant mieux....
Posté par schyzomarijks . Évalué à 2.
- LVM en mode snapshot et backuper le snapshot
- faire de la réplication MySQL et backuper le slave après avoir coupé la réplication
- Arkeia a une solution certifié de Sauvegarde à chaud MySQL http://www-fr.mysql.com/news-and-events/press-release/release_2005_(...)
>Postgres ne verrouille pas toute la table quand il fait une mise à jour/écriture d'un enregistrement.
Comme dit ci-dessus, le type de table InnoDB ne se vérrouille pas pour un insert ou un update.
et ca existe depuis assez longtemps (au moins 2002)
Bref, il faut apprendre à se servir d'un outil avant de FUDer.
[^] # Re: Tant mieux....
Posté par Jean-Max Reymond (site web personnel) . Évalué à 4.
- LVM en mode snapshot et backuper le snapshot
consistence des données ?
- faire de la réplication MySQL et backuper le slave après avoir coupé la réplication
une 2e machine dans le circuit, on peut rêver d'avoir plus simple.
- Arkeia a une solution certifié de Sauvegarde à chaud MySQL http://www-fr.mysql.com/news-and-events/press-release/release_2005_(...)
sur ce que j'ai vu, un bon gros lock donc pas loin de la solution mysql standard sauf qu'il n'y a pas besoin d'une 2e session.
[^] # Re: Tant mieux....
Posté par schyzomarijks . Évalué à 2.
"InnoDB Hot Backup is an online backup tool you can use to backup your InnoDB database while it is running. InnoDB Hot Backup does not require you to shut down your database and it does not set any locks or disturb your normal database processing."
Donc, ca existe aussi sans lock de table. Ceci dit, la solution Arkeia est vraiment bien et la sauvegarde incrementale est sans lock puisqu'elle utilise les logs.
"Arkeia’s MySQL plug-in runs incremental database backup based on the
MySQL binary log data. Each incremental backup includes only the log
of the operations since the last backup."
http://www.arkeia.com/pdfs/datasheets/others/Arkeia_MySQL_plugin.pd(...)
[^] # Re: Tant mieux....
Posté par herodiade . Évalué à 4.
une 2e machine dans le circuit, on peut rêver d'avoir plus simple.
On peut faire tourner le slave sur la même machine.
Plus sérieusement, les fonctionalités de replication de mysql sont excellentes pour ceux qui ont besoin de haute disponibilité: simples, bien intégrées, supportent le SSL etc.
Pour ce qui est des dumps, si on n'a pas peur des locks successifs sur les différentes tables (par exemple pour ceux qui n'ont pas une base ultra martyrisée en écriture, ou en faisant les dumps aux heures calmes), mysqldump est simple et bien pratique.
[^] # Re: Tant mieux....
Posté par netsurfeur . Évalué à 3.
Il est possible de verrouiller une base dans un état consistant avant de faire le snapshot:
[^] # Re: Tant mieux....
Posté par Prae . Évalué à 7.
Indéxation de data en rafale:
PostgreSQL mettait 3 ou 4 minutes à tout faire... tandis que MySQL avait mis une 30ène de seconde à tout caser dans sa DB...
Bon, maintenant, le test n'est plus tout jeune (~3 ans) donc peut-être plus valide ...
Perso, je dirais que MySQL et PosgreSQL sont fait pour deux types de dev ou d'archivages de données.
[^] # Re: Tant mieux....
Posté par schyzomarijks . Évalué à 5.
Parce que des gens avaient envie de le faire ?
>Je trouve simplement que c'est dommage, car postgreSQL est bien plus avancé que Mysql, et une alliance dès le départ aurait été bien plus bénéfique à tous.
Ca dépends des domaines. Par exemple les FAI choissisent MySQL pour sa facilité de maintenance et d'installation et de charge sur leurs architectures.
>PostgreSQL supporte tout ça depuis bien longtemps, et même beaucoup plus.
Que les clients de MySql est besoin de certaines fonctions et que AB répondent à leurs besoins
> Je trouve que c'est gacher, mais ça reste mon avis.
KDE contre gnome, voilà du vrai gachis :-)
L'outil ultime unique n'existe pas. Le LL permet d'avoir le choix et c'est bien (tm). Il existe des tas de sgbd libres, chacuns ayant une approche et une communauté différente. Ca encourage les autres a se dépasser. et ca aussi c'est bien.
[^] # Re: Tant mieux....
Posté par tuiu pol . Évalué à 8.
Les news sur les bêta et les RC il vaut mieux éviter mais sinon c'est un site collaboratif hein
[^] # Re: Tant mieux....
Posté par Jean-Christophe Arnu . Évalué à 6.
Je ne sais trop quoi répondre sauf que lorsqu'un produit sort, il faut s'en remettre à sa communauté. En l'occurence, il existe PostgreSQLFr où les PostgreSQL Weekly News sont traduits systématiquement. Notamment dans la dernière version du PWN on trouve l'article suivant : http://www.postgresqlfr.org/?q=node/386(...) . On peut effectivement taxer PostgreSQL de produit peu « marketé » mais il existe tout de même des sources d'information fiables et communautaires sur le sujet.
[^] # Re: Tant mieux....
Posté par Gyro Gearllose . Évalué à 6.
Ceci dit, j'aimerai rebondir sur ton post, car il me parle beaucoup. Quand tu dis que postgresql n'est pas très "marketé", je suis d'accord. Et justement, j'aurais bien voulu faire profiter la communauté linuxfr de cette nouvelle, en publiant un journal, voire en proposant une news. Après tout, ce n'aurait été que ma modeste contribution à ce projet que je venère.
Mais je ne l'ai pas fait. Pourquoi ? Simplement parce que la news sur le site de postgreSQL est on ne peut plus laconique, et que je n'avais pas le temps de chercher plus en profondeur. Et puis proposer une news avec un lien dedans, ou même un simple journal... Bref, si je n'ai rien d'autre à mettre dans le corps, autant ne rien mettre. Les gens intéressés par ce sgbd sont comme moi, ils savent bien cliquouiller sur un lien.
Du coup, j'ai profité de cette news pour glisser ça en fourbe... Juste retour des choses ! Il parrait qu'il ne doit pas y avoir de news sur les versions beta, rc, etc. Ben là, pourtant, c'est le cas....
M'enfin, il y avait matière à parler, et même si j'ai pu vous faire croire que je mérpisais mysql, son équipe de dev, la communauté même de mysql dans mon post initial, je m'en excuse, car ce n'est pas du tout ce que je pense.
C'est un outil que je n'utilise pas, et j'ai mes raisons (qui sont purement subjectives et hors propos), mais ça ne m'empêche pas d'admirer le travail qui a été fait.
Voilà, en espérant que ça rattrape un peu la sauce.
[^] # Re: Tant mieux....
Posté par Jean-Christophe Arnu . Évalué à 5.
Je suis tout à fait d'accord avec toi. Et je rebondis donc de manière (espérée) constructive. Actuellement l'équipe PostgreSQLFr (toute jeune, l'association n'a pas encore un an, bien que le site existe depuis plus longtemps) tente de s'organiser pour proposer des manchettes et des articles un peu plus étoffés et surtout qui permette d'avoir une meilleure visibilité sur ce SGBD. Il s'agit essentiellement de décrire des cas d'utilisations mais aussi d'expliquer un petit peu les nouvelles fonctionnalités et comment faire les choses (partager un savoir faire.
Nous disposons dans notre groupe de personnes ayant employé PostgreSQL dans des contextes professionnels divers et variés allant du web, biensûr, jusqu'à la logistique en passant par la sécurité civile par exemple. Ce sont autant de compétences sur divers sujets et qui peuvent répondre dans la majorité des cas aux questions que peuvent se poser les gens de la communauté d'utilisateurs.
Dans l'avenir une meilleure communication en français de ce que permet de faire PostgreSQL appuyé par des articles techniques viendront mettre en valeur le contenu déjà présent sur le site.
Comme toi, je tiens à préciser un peu les choses vis à vis de la communauté MySQL. Nous ne cherchons abosluement pas à discréditer un produit libre par rapport à un autre. Nous voulons « rester à notre place » en défendant notre produit et en faisant la chasse aux faux-semblants ou aux réputations qui ont vent sur le net et dans la communauté libre d'une manière générale.
# Oracle est loin
Posté par Franck Hanot . Évalué à 9.
De mon point de vue, les nouvelles capacités de mySql (triggers, vue et proc. stoc.) lui permettent seulement d'accéder au cercle des sgdbr dignes de ce nom.
Jusqu'à présent, l'absence de ces fonctions lui interdisait l'accès au marché pourtant énorme de l'informatique de gestion, domaine historiquement délaissé par le logiciel libre (heureusement, ça change).
Pour "se hisser à la hauteur d'Oracle" - sans parler d'OAS - il y aurait encore énormément de chemin à parcourir mais peu importe, l'intérêt de mySql réside dans sa simplicité d'administration, à l'*opposé* d'Oracle, db2, pgSql et consort.
[^] # Re: Oracle est loin
Posté par Jean-Christophe Arnu . Évalué à 8.
Je ne peux pas laisser dire que PostgreSQL est compliqué à administrer, c'est un lieu commun qui n'a pas lieu d'être justement. L'administration de PostgreSQL dans le cadre d'une infrastructure professionnelle est à mon avis moins contraignante que celle de MySQL. Par ailleurs l'excellente traduction de la documentation de PostgreSQL (merci à l'équipe de traduc.org) sur http://traduc.postgresqlfr.org/pgsql-8.0.3-fr/admin.html(...) donne un aperçu exhaustif de l'administration de PostgreSQL abordant à peu près tous les cas qui pourraient se retrouver dans un tel contexte professsionnel.
Quoi qu'il en soit, si on veut comparer MySQL à PostgreSQL sur ce plan là il faut bien comparer ce qui est comparable. Une complexité d'administration est à mettre en regard de la richesse fonctionnelle du moteur qui doit être administré. De ce fait, le critère de simplicité d'administration de MySQL pouvait être invoqué du fait de sa relative « pauvreté » fonctionnelle. Maintenant que quelques avancées sont dans la RC 1 de MySQL, je suis persuadé que l'administration va se compexifier un peu.
De la même manière, il faut aussi remettre les choses dans leurs contexte historique. Si on considère le bien-fondé de mon précédent paragraphe, il faut prendre en considération la configuration par défaut des produits. Cette configuration par défaut est un point important car elle résulte d'une expérience vécue par la communauté et qui permet d'affiner les différents paramètres par défaut aux situations les plus couramment rencontrées. Je ne dis pas que la version 5 de MySQL ne sera pas bien paramétrée au début, mais il y a de fortes chances que l'expérience fasse que ces paramètres évoluent dans le bon sens (celui de la généralité des cas de configuration). Par ailleurs, les effets de bords du «tuning» de paramètres ne seront connus puis documentés qu'avec le temps. De ce fait, des produits plus matures tels que PostgreSQL, Oracle ou tout autre moteur comportant déjà les nouvelles fonctionnalités incluses dans cette version de MySQL, auront toujours cette petite avancée qui s'appelle l'expérience des cas d'utilisation.
[^] # Re: Oracle est loin
Posté par Franck Hanot . Évalué à 1.
Néanmoins, je trouve que mySql a su évoluer fonctionnellement tout en gardant cet atout de la simplicité d'administration. De ce point de vue, il faudra bien surveiller l'implémentation des procédures stockées (d'ailleurs sont-elles réellement stockées? S'exécutent-elles dans le noyau ou dans un process indépendant?)
A propos de pgsql, j'aurais du la fermer, je ne l'ai jamais mis en oeuvre dans un cadre industriel ;o)
[^] # Re: Oracle est loin
Posté par billy . Évalué à 0.
Pour avoir testée les "nouvelles fonctionnalitée", je trouve qu'elle soit très mal intégrée et assez buggé. (view, procédures stockées)
Par exemple, il y a un tas d'erreurs avec mysqldump mysqlcheck et les vue...
Quand à la vitesse, c'est pas tellement mysql vs pgsql mais plutôt MySQL vs un vrai moteur de base de données.
innodb et pgsql c'est kif kif.
[^] # Re: Oracle est loin
Posté par Elrik de Melnibone . Évalué à 2.
Si oui, c'est une blague j'espere ! Quand je pense qu'il faut choisir un type de table dans mysql, je suis mort de rire !
Pour ce que je connais des autres bases, Postgresql est une des plus simple à administrer !
Il n'y a que sqlite qui fasse plus simple (et pour cause !)
[^] # Re: Oracle est loin
Posté par Franck Hanot . Évalué à 0.
Ca permet de privilégier soit les performances, soit l'intégrité des données.
Mieux, de par la modularité de mySql, on peut créer soi-même et plugger son propre système de stockage.
[^] # Re: Oracle est loin
Posté par Larry Cow . Évalué à 6.
Certes, mais ça ne joue pas en faveur de la simplicité.
Mieux, de par la modularité de mySql, on peut créer soi-même et plugger son propre système de stockage.
Ca c'est terrible. Quand tu récupères une base mise en oeuvre en utilisant cette particularité et que tu dois la maintenir, c'est noël en avance...
[^] # Re: Oracle est loin
Posté par Franck Hanot . Évalué à 3.
Oui, comme pour tout développement spécifique.
Si on utilise un système proposé par défaut (myIsam, innodb etc.), c'est sans soucis.
Cette fonctionnalité apporte un plus qui n'est pas forcément synonyme de complexité en terme d'administration. Cela permet simplement d'etre plus pointu en conception.
[^] # Re: Oracle est loin
Posté par Éric (site web personnel) . Évalué à 4.
Pourquoi ? ça n'a d'influence que si tu t'en sers. Il y a un type de table par défaut, tu peux très bien ignorer le fait qu'il y a plusieurs moteurs de table et mettre innodb par défaut si ça t'amuse
[^] # Re: Oracle est loin
Posté par LeMagicien Garcimore . Évalué à 10.
Youpiiiiiiiii je suis pas un spécialiste hein, mais un sgdb qui se fout de l'intégrité des données, ça sert à quoi ?
C'est un peu comme si pour un langage de prog on disait "ça va aller super vite, par contre l'execution est pas déterministe et on peut pas te dire si le résultat est le bon".
[^] # Re: Oracle est loin
Posté par Barnabé . Évalué à 8.
Il peut y avoir des données dont tu te soucies peu qu'elles survivent à un reboot intempestif, et d'autres pour lesquels c'est absolument nécessaire.
Par exemple pour un serveur de messagerie, tu as deux types d'information pour chaque utilisateur : ses données permanentes (nom, carnet d'adresse, ... ) et ses données volatiles (authentifiant de session, état de présence, ...).
Comme les données volatiles sont liées à la session, et que ce sont celles auxquelles on accède en ecriture, on se soucie peu de leur survie à un reboot, et il est très interessant pour les performances de pouvoir les mettre dans une table pus rapide.
Cette dualité données permanentes/données volatiles se retrouve dans bien des cas.
[^] # Re: Oracle est loin
Posté par Franck Hanot . Évalué à 2.
C'est vrai aussi que ça a donné de mauvaises habitudes.
[^] # Re: Oracle est loin
Posté par ours Ours (site web personnel) . Évalué à 2.
ca me semble relativement compliqué tout de même ...
[^] # Re: Oracle est loin
Posté par Bapt (site web personnel) . Évalué à 2.
Moi je n'ai jamais eu a recompiler mon kernel freebsd pour ça et mon postgresql tourne très bien ...
Je met peut être la bonne option dans le kernel dès les départ (je recompile toujours mon kernel après l'install), mais ça me parait étrange ce que tu dis.
[^] # Re: Oracle est loin
Posté par ours Ours (site web personnel) . Évalué à 1.
il y a deux solutions je pense, soit tu as une installation de pgsql assez "light", soit tu utilises les bons paramètres sans le savoir.
[^] # Re: Oracle est loin
Posté par FueL . Évalué à 4.
Moi la question que je me pose, c'est comment se comporte ces bases avec des données vitales contenant des millions d'enregistrements (style base de facturation d'un opérateur mobile) je pense que c'est un point de comparaison intéressant.
[^] # Re: Oracle est loin
Posté par Ngoc-Khoi TO . Évalué à 1.
[^] # Re: Oracle est loin
Posté par Jean-Yves Beaujean (site web personnel) . Évalué à 1.
Il suffit de regarder quels clients a MySQL pour s'en rendre compte.
[^] # Re: Oracle est loin
Posté par Anonyme . Évalué à 3.
[^] # Re: Oracle est loin
Posté par François B. . Évalué à 1.
Tout ça pour dire que la réputation d'oracle vient principalement des décideurs pressés, qui n'y connaissent rien à la technique, comme tout le monde le sait
[^] # Re: Oracle est loin
Posté par Raoul Volfoni (site web personnel) . Évalué à 5.
Beaucoup de personnes ici semblent ignorer les principales lacunes de PostGreSQL:
- pas de gestion du smp (multithreading)
- pas de partitionnement vertical ni horizontal des tables et index (tablespaces encore jeunes)
- pas de fonctionnalité de clustering comme sur la 10g
Bien entendu tout le monde n'as pas des applis qui insèrent 50 millions de lignes/24H dans des bases de 10To. Pour le reste, PostGreSQL est un excellent SGBDR qui tient très bien la charge sur des bases de taille moyenne (<1To) et peut parfaitement remplacer Oracle dans la majorité des cas.
Concernant mySQL, je suis comme la majorité des personnes s'interessant de près aux SGBDR depuis de longues années: ils arrivent trop tardivement pour que l'on puisse y porter un intérêt quelconque (car le temps d'investissement est loin d'être négligeable: on ne juge pas un SGBDR sur quelques benchs le temps d'un w-e!
# Berkeley DB vs MySQL
Posté par Chavenay . Évalué à 3.
# CSV
Posté par benp . Évalué à -2.
# infos complémentaires
Posté par BAud (site web personnel) . Évalué à 2.
m'a indiqué cet article un peu partial :
http://www.sqlsummit.com/articles/MySQL5.htm(...)
qui signale notamment : "MySQL distributed transactions conform to the X/Open XA specification, using global transactions and two-phase commit" ce qui permet d'avoir des transactions aux propriétés ACID http://fr.wikipedia.org/wiki/Propri%C3%A9t%C3%A9s_ACID(...) (la version en anglais étant encore un peu plus détaillée... http://en.wikipedia.org/wiki/ACID(...) ).
# MySQL 5.0 officiellement sortie
Posté par Loïc Jaouen . Évalué à 1.
http://www.mysql.com/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.