MySQL 5.0 : Release Candidate 1

Posté par (page perso) . Modéré par Florent Zara.
Tags :
0
29
sept.
2005
Base de données
MySQL, le plus célèbre serveur de base de données OpenSource, vient de publier la première version release candidate de la branche 5.0. Cette phase de test constitue donc la dernière ligne droite avant la publication d'une version certifiée stable et utilisable en production.

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

  • # PG

    Posté par (page perso) . Évalué à 10.

    Maintenant que tout le monde est passé à PostgreSQL -- ne pouvant attendre ces longues années pour bénéficier du support des procédures stockées, des vues et des triggers -- et que depuis tout ce temps PostgreSQL n'a pas eu à rougir devant Oracle (dans l'immense majorité des cas), y a-t-il une bonne raison pour repasser à MySQL ?
    • [^] # Re: PG

      Posté par (page perso) . Évalué à 10.

      Pourquoi se fait-il moinsser ?
      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 (page perso) . Évalué à 8.

      Surtout que dans le même temps, Postgres avance aussi.
      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 . Évalué à 5.

        Oui enfin, il faut bien voir aussi que moi qui fait du développement de site Internet, je n'ai pas vraiment le choix au niveau hébergement, à moins d'avoir un serveur dédié on nous fournit Mysql comme base de données..
      • [^] # Re: PG

        Posté par . Évalué à 1.

        Il faut aussi parler l’héritage des tables. C’est un excellent point de postgresql. Avec cette fonctionnalité on peut facilement faire évolué le schéma de système d’information.
        • [^] # Re: PG

          Posté par . Évalué à 2.

          Désolé, j’arrive pas à trouvé le lien pour modifier les caractères html
          • [^] # Re: PG

            Posté par . Évalué à 2.

            Faut dire qu'utiliser le guillemet anglais simple fermant (right single quote, ’ ou ’ « ’ ») à la place de l'apostrophe (ʼ « ʼ » ou, plus simplement, ' « ' »), ça doit pas aider¹...

            ¹ : Remarquons que j'y arrive bien (en tout cas, ça fonctionne dans le « Vérifier »)...
  • # Tant mieux....

    Posté par . Évalué à 10.

    Je ne comprendrai jamais pourquoi les efforts faits pour faire progresser mysql n'ont pas été abandonnés dès le départ au profit de postgresql.
    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 . Évalué à 9.

      Ce que tu décris là est, à mon avis, symptomatique de ce qui se passe dans le monde des Logiciels, ceux qui font le plus de Buzz (pub, annonces...) sont les plus connus (et reconnus) même si il existe de meilleurs solutions.
      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 (page perso) . Évalué à 9.

        Toutes ces grandes théories sont bien amusantes, mais en tant que serveur de base de données pour des applications web, PostgreSQL n'a pas fait ses preuves.
        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 . Évalué à 1.

        en parlant de troll

        "On n'a pas parler de ça, linuxfr c'était mieux a vent!".


        Non !linuxfr c'etait mieux à eau, comme les moulins
        =========>[ ]
      • [^] # Re: Tant mieux.... mais ...

        Posté par . Évalué à 2.

        Mon soucis est la communication... mon client lamda (collectivité locale pour l'essentiel) connais bien MySQL, ou plus largement LAMP... Postgresql est plus difficile à proposer. D'autant que la plupart des hébergeurs proposent / communiquent uniquement sur MySQL. Les "marques" Linux, Apache, MySQL et PHP sont intimement lié et passe bien.
    • [^] # Re: Tant mieux....

      Posté par (page perso) . Évalué à 7.

      on finira par avoir le choix entre deux logiciels qui proposent exactement les mêmes fonctionnalités

      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 (page perso) . Évalué à 8.

        avec les tailles mémoires disponibles, on surprend Postgres plus rapide que Mysql avec une base entièrement en mémoire. C'est ce qu'avait observé Decision Micro à leur grande surprise et puis Postgres ne verrouille pas toute la table quand il fait une mise à jour/écriture d'un enregistrement sans parler des sauvegardes à chaud...
        • [^] # Re: Tant mieux....

          Posté par . Évalué à 2.

          par défaut en effet, mais sauf erreur, avec une table InnoDB, seule la ligne est lockée en mysql.
          • [^] # Re: Tant mieux....

            Posté par (page perso) . Évalué à 3.

            certes mais bon, InnoDB, faut vraiment être maso
            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.
            • [^] # Re: Tant mieux....

              Posté par . Évalué à 2.

              Un très net ralentisssement ? Je suis intéressé par ce qui te permet de jeter cette affirmation en pâture : aurais-tu des liens mettant en évidence ce "très net ralentissement". Parce que justement, InnoDB est connu pour être un moteur supportant les transactions de manères très véloce, et il semblerait que ce ne soit pas par hasard que le géant de la base de donné nommé Oracle s'y intéresse de très près [1] ...

              [1] http://linuxfr.org/2005/10/12/19710.html

              « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

        • [^] # Re: Tant mieux....

          Posté par . Évalué à 2.

          Pour les sauvegardes à chaud il y a au moins 3 solutions : cf http://linuxfr.org/~govenka/8311.html(...)

          - 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 (page perso) . Évalué à 4.

            Pour les sauvegardes à chaud il y a au moins 3 solutions : cf http://linuxfr.org/~govenka/8311.html(...)(...)

            - 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 . Évalué à 2.

              il y a aussi Innodb-hotbackup

              "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 . Évalué à 4.

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


              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 . Évalué à 3.


              - LVM en mode snapshot et backuper le snapshot
              consistence des données ?

              Il est possible de verrouiller une base dans un état consistant avant de faire le snapshot:

              FLUSH TABLES WITH READ LOCK
              lvcreate --snapshot ...
              UNLOCK TABLES
        • [^] # Re: Tant mieux....

          Posté par . Évalué à 7.

          Je me souviens aussi d'un test qu'on avait fait pour un dev.
          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 . Évalué à 5.

      >Je ne comprendrai jamais pourquoi les efforts faits pour faire progresser mysql n'ont pas été abandonnés dès le départ au profit de postgresql.

      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 . Évalué à 8.

      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.

      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 . Évalué à 6.

      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.

      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 . Évalué à 6.

        Je suis pratiquement d'accord avec toutes les réponses faites à mon post, qui tentait un peu de dire des choses "sensées" sans trop lacher de troll (enfin, un peu quand même, on est sur linuxfr, après tout !).
        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 . Évalué à 5.

          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.

          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 . Évalué à 9.

    Bonjour,

    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 . Évalué à 8.

      Bonjour,

      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 . Évalué à 1.

        Je suis d'accord avec ça, si mySql est simple à administrer, c'est du fait de la simpllicifté de son architecture, et de cette "relative « pauvreté »".
        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 . Évalué à 0.

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



          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 . Évalué à 2.

      Je lis bien pgSQL difficile à administrer ? On parle bien de postgreSQL ?

      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 . Évalué à 0.

        Le choix du type de table est une très bonne chose.
        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 . Évalué à 6.

          Le choix du type de table est une très bonne chose.

          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 . Évalué à 3.

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

            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 (page perso) . Évalué à 4.

            > Certes, mais ça ne joue pas en faveur de la simplicité.

            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 . Évalué à 10.

          Ca permet de privilégier soit les performances, soit l'intégrité des données.

          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 . Évalué à 8.

            Cela dépend de ton application.
            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 . Évalué à 2.

            Jusqu'à la 3.23 mySql ne gérait pas l'intégrité référencielle des données. Et pourtant il a su trouver un public qui trouvait là un outil de recherche simple et *très* rapide.
            C'est vrai aussi que ça a donné de mauvaises habitudes.
      • [^] # Re: Oracle est loin

        Posté par (page perso) . Évalué à 2.

        en même temps, si tu veux utiliser pgsql sous freebsd, tu es obligé de recompiler le noyau (à cause des sémaphores)
        ca me semble relativement compliqué tout de même ...
    • [^] # Re: Oracle est loin

      Posté par . Évalué à 4.

      Pour ce qui est d'Oracle, je sais pas si bcp d'entre vous administre ce type de base, mais même si elle est solide, sur Oracle entre la création des dictionnaires, la gestion des tablespaces, des clauses "storage" des tables et index, le listenner, le dimmensionnement des tables, index etc... je peux dire que c'est vraiment ce qu'il m'est été donné de plus simple à administrer.

      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 . Évalué à 1.

        Oui , le problème ce trouve dans les bases avec des données vitales contenant des millions d'enregistrements. Je n’utilisera pas mysql pour les bases plus de 50 k d’enregistrements. Car, c’est les tablespaces qui donne la sécurité par rapport au chaînage des clusters du filesystem. Et c’est les index Btree, hash, Qtree qui donnent la performance. Oui , c’est du travaille, mais grâce à ça qu’on a du boulot :-)
        • [^] # Re: Oracle est loin

          Posté par (page perso) . Évalué à 1.

          Je pense au contraire, que MySQL peux se montrer à la hauteur lorsqu'il s'agit de la gestion de base de données colossales.

          Il suffit de regarder quels clients a MySQL pour s'en rendre compte.
          • [^] # Re: Oracle est loin

            Posté par (page perso) . Évalué à 3.

            Et il faut aussi regarder quels clients mysql n'a pas ! Dans ce sens que Oracle à bati un nom, une marque et qu'il existe pas mal de gens qui utilisent Oracle parce qu'ils ont confiance en cette marque. Ou, plus prosaïquement, parce que ça donne à leur logiciels une dimension plus sérieuse (*ouais mon machin, il est tellement puissant qu'il a besoin d'Oracle !* :)) ).
            • [^] # Re: Oracle est loin

              Posté par . Évalué à 1.

              Bof... Du temps de la "bulle internet", si tu voulais attirer des fonds dans ta startup, tu devais utiliser oracle ! Même si tu utilisais une autre base propriétaire valable, ou même si tu n'avais pas besoin de base, c'était le seul moyen pour que les "capital risque" s'intéressent à toi.

              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 (page perso) . Évalué à 5.

        Je partage totalement ton avis. Peut-être est-ce parce que nous avons visiblement travaillé sur les même applis: InterconnecT?

        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 . Évalué à 3.

    Comment se situe Berkeley DB par rapport à MySQL ?
  • # CSV

    Posté par . Évalué à -2.

    Je réclame une comparaison point à point de mysql 5 et CSV !
  • # infos complémentaires

    Posté par (page perso) . Évalué à 2.

    /. sur http://developers.slashdot.org/developers/05/10/05/2041240.shtml?ti(...)
    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 . Évalué à 1.

    ça y est, c'est fait, la version 5.0 est officiellement sortie:

    http://www.mysql.com/

    October 24, 2005 -- MySQL AB, developer of the world's most popular open source database, today announced the general availability of MySQL 5.0, the most significant product upgrade in the company's ten-year history. Starting today, MySQL 5.0 can be downloaded under the open source GPL license at http:/dev.mysql.com.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.