vendredi 25 juillet
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

: MySQL 5.0 est sorti

Posté par tuiu pol (Jabber id, ). Modéré le 27 octobre 2005.
Le lundi 24 octobre, MySQL AB a annoncé la sortie de la version 5.0 du plus célèbre serveur de base de données Open-Source.

C'est la version 5.0.15 de la série 5.0.x qui a été déclarée stable, un an après la sortie de la version 4.1.7, version officielle de la série 4.1.x.

Cette nouvelle version fournit des fonctionnalités longtemps attendues comme :
  • 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)

La version est disponible en téléchargement, pour un nombre considérable de plateformes : GNU/Linux(x86/AMD64/IA64/Alpha), Windows, Solaris, Mac OS X, FreeBSD, HP-UX, IBM AIX, QNX, Novell NetWare, SCO, OpenBSD, SGI Irix.

Comme les versions précédentes, MySQL 5.0 est régi par une double-licence : la GPL et une licence commerciale pour les revendeurs, ou les développeurs ne souhaitant pas livrer le code source.

NdM Merci à Cedric Bellec de nous avoir également proposé cette information

> Lire la dépêche (70 commentaires, moyenne: 2,1).  

Vous avez demandé le commentaire #641644.

Que de temps pour les vues ...

Posté par Stéphane TRAUMAT (page perso, ) le 27/10/2005 à 07:46. (lien). Évalué à 4.

Bon, perso, je suis pas du tout fan des procédures stockées et des triggers ! mais attendre tout ce temps pour avoir les vues, ca me parait vraiment incroyable, c'était si difficile que ça à développer ?

  • [^]Re: Que de temps pour les vues ...

    Posté par David Pradier (page perso, ) le 27/10/2005 à 08:12. (lien). Évalué à 2.

    Qu'est-ce que tu as contre les procédures stockées et les triggers ?

    • [^]Re: Que de temps pour les vues ...

      Posté par Stéphane TRAUMAT (page perso, ) le 27/10/2005 à 08:19. (lien). Évalué à 2.

      Disons que je préfère travailler en objet et rester complètement indépendant de la base de données choisie.

      • [^]Re: Que de temps pour les vues ...

        Posté par Stéphane TRAUMAT (page perso, ) le 27/10/2005 à 08:39. (lien). Évalué à 1.

        Plutôt que d'être moinsser, j'aimerais avoir un commentaire qui m'explique ce qui vous plait pas dans mon commentaire précédent ?

        • [^]Re: Que de temps pour les vues ...

          Posté par Christophe Garault (page perso, ) le 27/10/2005 à 12:11. (lien). Évalué à 7.

          > j'aimerais avoir un commentaire qui m'explique ce qui vous plait pas dans mon commentaire précédent ?

          Un troll plus velu qu'un mamouth souffrant d'une crise de pilosité aigüe?
          On en a déjà parlé maintes fois Stéphane: pour tous les DBA de la terre, la meilleure façon d'être indépendant du SGBD c'est d'adopter la même stratégie multicouches que dans vos applis: un schéma physique inconnu des développeurs, un schéma logique à base de vues, de procédures stockées et de triggers conçu pour une appli comme un contrat entre l'équipe de devt et les DBA. Si l'on commence à mettre du SQL dans le code des applis c'est foutu pour tout le monde...

          • [^]Re: Que de temps pour les vues ...

            Posté par Stéphane TRAUMAT (page perso, ) le 27/10/2005 à 12:19. (lien). Évalué à 2.

            ce n'est pas la meilleure façon d'etre indépendant de la base de données :) En effet, je comprends le troll !
            La meilleure façon c'est de toute développer en objet et de laisser un outil de mapping O/R gérer le tout !

            [^]Re: Que de temps pour les vues ...

            Posté par Aurélien Girard () le 27/10/2005 à 13:35. (lien). Évalué à 2.

            En plus les procédures stockées ça va super vite !

      [^]Re: Que de temps pour les vues ...

      Posté par zorel () le 27/10/2005 à 08:22. (lien). Évalué à 2.

      Tu colles du traitement orienté fonctionnel dans un machin qui n'est pas prévu pour, c'est pas portable, c'est difficile a débugguer.

      • [^]Re: Que de temps pour les vues ...

        Posté par Marc () le 27/10/2005 à 09:05. (lien). Évalué à 3.

        Tu n'es pas obligé de mettre du fonctionnel dans les procédures stockées. Tu peux te limiter à l'accès aux données...
        Ca évite tout de même de faire de nombreuses requêtes successives au moteur pour récupérer quand les données à récupérer sont complexes. C'est très utile par exemple quand le réseau entre la BDD et le serveur d'appli peut avoir un impact sur les temps de réponse de requêtes simples (par exemple, serveur BDD dans une DMZ).
        Ca peut aussi permettre de vérifier des contraintes complexes à l'insertion des données (genre si ma colonne A vaut tant et ma colonne B est comprise entre telle et telle valeur, j'empeche telle action).
        Evidemment, écrire un traitement fonctionnel de plusieurs dizaines de milliers de lignes en PLSQL par exemple, c'est aimer se faire mal... et je présume que c'est plutôt à cela que tu pensais.

        • [^]Re: Que de temps pour les vues ...

          Posté par zorel () le 27/10/2005 à 09:10. (lien). Évalué à 1.

          > C'est très utile par exemple quand le réseau entre la BDD et le serveur d'appli peut avoir un impact sur les temps de réponse de requêtes simples (par exemple, serveur BDD dans une DMZ).

          Les serveurs applicatifs sont pas non plus dans la DMZ? C'est mal(r).

          > Ca peut aussi permettre de vérifier des contraintes complexes à l'insertion des données (genre si ma colonne A vaut tant et ma colonne B est comprise entre telle et telle valeur, j'empeche telle action).

          C'est pas du traitement fonctionnel ça?

          • [^]Re: Que de temps pour les vues ...

            Posté par Marc () le 27/10/2005 à 09:16. (lien). Évalué à 5.

            > Les serveurs applicatifs sont pas non plus dans la DMZ? C'est mal(r).
            Mpff ... pas dans la même. C'est CA la vraie paranoïa... :) Ca fait quand même un firewall à traverser.

            >> Ca peut aussi permettre de vérifier des contraintes complexes à l'insertion des données (genre si ma colonne A vaut tant et ma colonne B est comprise entre telle et telle valeur, j'empeche telle action).

            > C'est pas du traitement fonctionnel ça?

            Je pense que c'est à la limite... Ca dépend des raisons de la contrainte.
            C'est avant tout de la vérification de cohérence à l'insertion. Ca permet d'être sur que même si tu as un développeur qui veut corriger en urgence une donnée dans une table (qu'il aurait amenée avec un autre programme) et lance un ordre UPDATE à la main (oui, déja vu, malheureusement) ne te vérole pas totalement ta base si il a oublié un petit détail. En théorie, le développeur ne devrait pas avoir accès à la base de prod en direct, mais il y a des environnements ou tout est permis.

            Evidemment, tout est dans le savant dosage, et dans la capacité à savoir s'arrêter dans les contraintes d'intégrité. De la à ne pas en mettre du tout parce qu'on est sur de son code ou parce que le PL c'est moche ...

            [^]Re: Que de temps pour les vues ...

            Posté par Infernal Quack (Jabber id, page perso, ) le 27/10/2005 à 09:26. (lien). Évalué à 2.

            "C'est pas du traitement fonctionnel ça?"

            Bretelles et ceintures comme dirait un collègue.

            • [+] [^]Re: Que de temps pour les vues ...

              Posté par zorel () le 27/10/2005 à 09:30. (lien). Évalué à -5.

              Ou incompétence du développeur qui a peur que son code fonctionne pas?

              • [^]Re: Que de temps pour les vues ...

                Posté par Marc () le 27/10/2005 à 09:34. (lien). Évalué à 6.

                Je ne crois pas que développer un logiciel de façon professionnelle ait voir avec la peur.
                Mettre des contraintes, c'est une question de robustesse. Si tu mets une contrainte au niveau de la base, tu es sur que personne ne peut la court-circuiter (sauf en la désactivant, bien sur). Cette contrainte ne change en rien le code qui est derrière, et peut t'économiser pas mal de soucis (comprendre : de travail, pas de peur...) en te protégeant de tes propres erreurs.

                [^]Re: Que de temps pour les vues ...

                Posté par Infernal Quack (Jabber id, page perso, ) le 27/10/2005 à 09:36. (lien). Évalué à 7.

                Non : Cohérence de données à risque.

                Qui plus est, l'erreur est humaine. Alors autant tout faire pour l'éviter.

    [^]Re: Que de temps pour les vues ...

    Posté par Aurélien Bompard (Jabber id, page perso, ) le 27/10/2005 à 08:58. (lien). Évalué à 2.

    Je suis pas DBA et je dis probablement une connerie, mais allez, on est sur linuxfr.org après tout... Il me semble que les vues ne servent pas à grand chose sans triggers. Dans mon souvenir, ce sont les triggers qui mettent à jour les vues.

    • [^]Re: Que de temps pour les vues ...

      Posté par Marc () le 27/10/2005 à 08:59. (lien). Évalué à 3.

      Uniquement pour des vues "matérialisées".
      Le reste du temps, une vue, c'est a peu près rien d'autre qu'une règle de réécriture de requête.

      • [^]Re: Que de temps pour les vues ...

        Posté par Aurélien Bompard (Jabber id, page perso, ) le 27/10/2005 à 09:26. (lien). Évalué à 2.

        Ah, si ce type de vues est implémenté dans MySQL 5, ça peut être l'explication.

        [^]Re: Que de temps pour les vues ...

        Posté par Papey () le 27/10/2005 à 15:38. (lien). Évalué à 1.

        MMmmm, pas seulement pour les vues matérialisées, non. Les vues simples (sans jointures) permettent de mettre à jour un sous-ensemble de champs d'une table plus grande, par exemple. A partir de là tu peux mettre un trigger pour remplir d'autres champs (non accessibles directement à l'utilisateur) à la volée.

      [^]Re: Que de temps pour les vues ...

      Posté par Stéphane TRAUMAT (page perso, ) le 27/10/2005 à 08:59. (lien). Évalué à 2.

      Pas du tout :) les vues ne sont pas du tout liées aux triggers. Nous nous servons des vues pour que les gens qui veulent des stats puissent les obtenir facilement.

      En gros, on leur fait toutes les jointures comme ça, ils s'embettent pasa trop pour leurs stats

      • [^]Re: Que de temps pour les vues ...

        Posté par Aurélien Bompard (Jabber id, page perso, ) le 27/10/2005 à 09:24. (lien). Évalué à 2.

        Bon, bien tenté :)
        Je pensais qu'un des intérêts des vues était aussi les perfs. Apparemment pas, merci pour l'info.

        • [^]Re: Que de temps pour les vues ...

          Posté par Marc () le 27/10/2005 à 09:27. (lien). Évalué à 2.

          Pour les perfs, il y a les vues dites matérialisées (sous Oracle au moins). Ca consiste à fabriquer une table qui contient en permanence exactement le contenu qu'aurait ta vue. C'est surtout utilisé pour les bases sur lesquelles on fait du data mining, afin de préparer les résultats des requêtes les plus complexes (regroupements sur des grands nombres d'enregistrements par exemple).
          Ca n'existe pas pour le moment sous PostgreSQL ou Mysql. On peut le faire avec des triggers, mais c'est quand même pas mal de boulot...

          Une vue normale n'accélère pas les perfs. Ca ne fait que simplifier le développement.

          • [^]Re: Que de temps pour les vues ...

            Posté par Volnai () le 27/10/2005 à 09:41. (lien). Évalué à 1.


            Ca consiste à fabriquer une table qui contient en permanence exactement le contenu qu'aurait ta vue

            Euh non pas forcement. La vue materialisé peut n'être mise à jour qu'a intervalles réguliers, et donc être "décalé" par rapports aux données de la table.

            • [^]Re: Que de temps pour les vues ...

              Posté par Marc () le 27/10/2005 à 09:45. (lien). Évalué à 1.

              Oui, je simplifiais ... par en permanence je voulais dire que le résultat est en permanence présent dans la base, pas recalculé à chaque demande. mais les données peuvent être décalées suivant la facon dont tu déclares la vue matérialisée...

            [^]Re: Que de temps pour les vues ...

            Posté par Christophe Garault (page perso, ) le 27/10/2005 à 11:54. (lien). Évalué à 1.

            > Ca n'existe pas pour le moment sous PostgreSQL ou Mysql.

            Deux procédures stockées suffisent à le réaliser soi-même.

            • [^]Re: Que de temps pour les vues ...

              Posté par Marc () le 27/10/2005 à 12:16. (lien). Évalué à 1.

              C'est pas que j'aime pas Mysql ou PostgreSQL, mais ce que tu peux faire avec des triggers n'est pas exactement la même chose : une requête qui rame sous Oracle, si je peux lui demander de s'appuyer sur une vue matérialisée (il y a des choses qu'on ne peut pas faire...), je peux le faire de façon transparente pour le développeur ou l'utilisateur : le moteur réécrira dans son dos la requête pour utiliser la vue matérialisée plutôt que de lire la table. Cela évite de toucher au code de l'application.
              Donc c'est faisable sous PostgreSQL ou Mysql avec des procédures stockées, et des triggers pour les mettre à jour, mais sans la réécriture automatique des requêtes, qui est bien extrèmement pratique. Peut être avec des rules PosgreSQL, mais ca peut vite devenir lourd à gérer.
              Enfin, de toutes façons, là on parle de grosses bases décisionnelles, c'est pas encore la cible pour Pg ou Mysql à ma connaissance.

              • [^]Re: Que de temps pour les vues ...

                Posté par Christophe Garault (page perso, ) le 27/10/2005 à 13:03. (lien). Évalué à 2.

                > Donc c'est faisable sous PostgreSQL ou Mysql avec des procédures stockées, et des triggers pour les mettre à jour, mais sans la réécriture automatique des requêtes, qui est bien extrèmement pratique.

                Je pensais à la mise à jour de la table remplaçant la vue matérialisée par une sp plannifiée, mais les possibilités d'implémentations sont de toutes façons nombreuses, comme pour la réplication.

                Par contre je ne comprend pas tout à fait ce que tu entends par réécriture automatique des requêtes. C'est propre à Oracle 10g cette utilisation transparente des vues matérialisées? Je ne l'ai jamais rencontré. (pas été plus loin que la v9)

                > Enfin, de toutes façons, là on parle de grosses bases décisionnelles, c'est pas encore la cible pour Pg ou Mysql à ma connaissance.

                Pour mySQL peux-être pas en effet, mais il existe de magnifiques projets pour PostgreSQL:
                http://www.bizgres.org/
                Metapa (dsl pas l'url)
                Un projet Olap dont je n'ai pas non plus retrouvé l'url mais qui est très prometteur (je vais fouiller mes bookmarks)

                Et pour les vues matérialisées, il existe aussi un projet:
                http://gborg.postgresql.org/project/matview/projdisplay.php

                ps: la version 8.1 de PotgreSQL sera une avançée majeure. Peut-être qu'une news est déjà prévue?

                • [^]Re: Que de temps pour les vues ...

                  Posté par Christophe Garault (page perso, ) le 27/10/2005 à 13:16. (lien). Évalué à 2.

                  > Un projet Olap dont je n'ai pas non plus retrouvé l'url mais qui est très prometteur (je vais fouiller mes bookmarks)


                  Ca y est, c'est le projet Mondrian. Ca va faire plaisir à S. Traumat c'est écrit en Java ;)

                  http://mondrian.sourceforge.net/

                  • [^]Re: Que de temps pour les vues ...

                    Posté par Stéphane TRAUMAT (page perso, ) le 27/10/2005 à 13:23. (lien). Évalué à 0.

                    Ca y est :) j'ai ma réputation !
                    Achetez mon livre !!!

                    • [+] [^]Re: Que de temps pour les vues ...

                      Posté par Gabriel () le 27/10/2005 à 15:04. (lien). Évalué à -1.

                      <ilVautMieuxPerdreUnAmiQuUnBonMot>

                      Oui enfin, tu as ta réputation ça ne veut pas dire qu'elle est bonne!

                      </ilVautMieuxPerdreUnAmiQuUnBonMot>

                      --
                      Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying

                  [^]Re: Que de temps pour les vues ...

                  Posté par Marc () le 27/10/2005 à 13:22. (lien). Évalué à 2.

                  >Par contre je ne comprend pas tout à fait ce que tu entends par réécriture automatique des requêtes. C'est propre à Oracle 10g cette utilisation transparente des vues matérialisées? Je ne l'ai jamais rencontré. (pas été plus loin que la v9)

                  Ca existe au moins en 9i, même si il y a des nouveautés je crois en 10g sur le sujet :
                  http://www.oracle.com/technology/oramag/oracle/03-sep/o53bus(...)

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0989s (dont 0.0075 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.