MySQL 5.0 est sorti

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
0
27
oct.
2005
Base de données
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 Le changelog (traduction libre et limitée):
  • BIT Data Type: Peut être utilisé pour stocker les nombres en notation binaire.
  • Cursors: Support élémentaire pour les cursors SSI.
  • Information Schema: Introduction de la base de données INFORMATION_SCHEMA qui fournit une méthode standard pour accéder aux métadonnées du serveur.
  • Instance Manager: Peut être utilisé pour démarrer et arrêter le serveur MySQL même à distance.
  • Precision Math: Introduction d'un critère strict pour accepter ou rejeter une donnée et implémentation d'une nouvelle bibliothèque d'arithmétique à virgule fixe.
  • Storage Engines: Ajout des moteurs de stockages ARCHIVE et FEDERATED.
  • Stored Routines: Support des procédures stockées et des fonctions stockées.
  • Strict Mode and Standard Error Handling: Ajout d'un mode strict qui suit d'avantage la norme SQL qu'auparavant. Support de l'erreur standard SQLSTATE.
  • Triggers: Ajout limité du support des triggers.
  • VARCHAR Data Type: La longueur maximale effective pour une colonne VARCHAR est repoussée à 65,532 bytes.
  • Views: Ajout du support pour les vues nommées.
  • XA Transactions
  • Performance enhancements: Un nombre d'améliorations ont été dans MySQL 5.0 pour accélérer certaines demandes et dans la gestion de certains types.

Aller plus loin

  • # Oh oui !

    Posté par  (site web personnel) . Évalué à 1.

    Voila une nouvelle qui fait bien plaisir de bon matin.
    Je n'ai pas encore eu la chance de tester ce nouveau jouet mais d'apres ce qu'on peut en lire, cette version est un reel tournant oriente performance pour mysql.

    Mysql sera-t-il malgre tout relegue loin derriere SQLserver et Oracle ?
    Quoi qu'il en soit, bravo a l'equipe de developpement !

    • [^] # Re: Oh oui !

      Posté par  . Évalué à 0.

      Effectivement on ne peut que se rejouir de la profusion de bon outils sortis ces dernier temps.

      En ce qui concerne le rapport avec SQLserver et Oracle, les devs de Mysql ont tout d'abord intérêt à faire évoluer la qualité pure de leur SGBDR cf: http://www.phpbuilder.com/columns/tim20001112.php3?page=1

      • [^] # Re: Oh oui !

        Posté par  . Évalué à 2.

        Je pense qu'un article de cinq ans d'age (en regardant la date du premier commentaire) n'est pas vraiment pertinent, et en l'occurence en utilisant InnoDB, on passe d'un table-level locking à un row-level locking...

        • [^] # Re: Oh oui !

          Posté par  . Évalué à 2.

          En attendant, c'est un des seuls articles traitant d'une comparaison entre SGBDR libres sans utiliser une fois encore les outils de benchmarking de chez Mysql AB.

          Sans vouloir une fois de plus discréditer le travail fait au sein de Mysql AB, je serais relativement étonné que leur outil de mesure de performance soit totalement neutre. Allons, voyons, comment une société pourrait-elle passer du temps et dépenser de l'argent pour devellopper un outil qui revelerait l'infériorité de leur produit sur leurs concurrents ?

          Encore une fois, je ne dis pas que Mysql est de la merde, que les fonctionnalités implémentées sont pauvres ou autres, simplement que niveau performances pures, ils pourraient faire des efforts.

    • [^] # Re: Oh oui !

      Posté par  . Évalué à 1.

      D'après quelques échos il semble que le gain de performances est réel pour cette nouvelle version.

      Par ailleurs je me pose une question (bête), j'ai vu passer le fait que le format innodb à été racheté / acheté ou que "mysql se l'est fait piqué". Or à ma connaissance c'était un des seuls formats à l'époque de la 4.0.x qui permettait de faire des clef étrangères dignes de ce nom contrairement au format habituel et certes plus light myisam.

      Ma question est la suivante : Y a-t-il toujours innodb dans mysql ou un autre format propose-t-il les mêmes fonctionnalités ? (J'imagine que oui puisque les triggers, prosto et autres sont enfin arrivées...)

      Merci pour vos réponses, amicalement, Vivi.

      • [^] # Re: Oh oui !

        Posté par  . Évalué à 4.

        La réponse est tout bête:
        - Les nouvelles fonctionnalités ne dépendent d'aucun storage engine. Donc on retrouve les triggers, stored procedures et les views sur MyISAM
        - InnoDB est en double license GPL/Commercial
        - MySQL a un contrat avec Innobase qui court jusqu'en 2007 ce qui laisse un peu de marge.

        L'incertitude est surtout au niveau de InnoDB Hot Backup, l'outil de backup à chaud ultra-rapide de Innobase utilisé souvent dans boîtes pour leurs sauvegardes/restorations (même si on peut faire un backup à chaud facilement avec InnoDB, toutefois cela sera plus lent)

        • [^] # Re: Oh oui !

          Posté par  . Évalué à 1.

          Merci pour cette réponse précise et pertinente.

          Cependant :

          Les nouvelles fonctionnalités ne dépendent d'aucun storage engine. Donc on retrouve les triggers, stored procedures et les views sur MyISAM


          Ceci est-il valable pour les nouvelles fonctionnalités uniquement (celles de la 5.0) ou d'une manière générale ?

          Car recemment j'ai découvert après tests que l'implémentation de contraintes structurelles simples comme les clef étrangères ou choses du genre ne fonctionnnaient qu'avec InnoDB en mysql 4.0.x du moins...

          Avec la même table en myisam j'arrivais très bien a insérer des données en dépit d'un foreign key ... references ... alors que la donnée référencée n'existe pas. Idem pour supprimer (sans parler de cascade).

          Du coup autre question ces contraintes sont-elles disponnibles desormais même en myisam ?

          NdM : je sais j'ai qu'à fouiller ou installer mysql5 et tester mais bon c'est pas ultra rapide pour avoir une réponse, hein ? ;-). Merci en tous cas.

          Amicalement, Alban.

          • [^] # Re: Oh oui !

            Posté par  . Évalué à 2.

            En fait, il y a deux niveaux de fonctionnalités:
            - les fonctionnalités comme les triggers, stored procédures sont implémentées directement dans le serveur
            - les fonctionnalités d'intégrité sont propres à chaque engine ie le moteur responsable de chercher/mettre à jour les données physiquement. (Pour le développeur, un engine, c'est juste une classe avec une quinzaine de méthodes appelées par le serveur). A ce jour seul InnoDB implémente les contraintes d'intégrités.

            Conséquence si une fonctionnalité (comme le CASCADE DELETE) du serveur dépend d'une fonctionnalité de l'engine, elle ne marchera pas si l'engine ne l'implémente pas.

            En ce qui concerne les dernières features, elles ne font pas appel aux contraintes d'intégrités donc elles sont dispos sous MyISAM et InnoDB (et les autres engine bien sûr)

    • [^] # Re: Oh oui !

      Posté par  . Évalué à 1.

      question perfs pures, mysql est au même niveau qu'oracle (tant qu'on est pas en cluster) et bat sql server (enfin, sql server 2000, ça c'est certain, les autres j'ai pas vu de benchs), mais pour les entreprises, le débat n'a jammais été une question de performaces pures mais de fonctionnalités et de support, et dans ces derniers points, mysql ab a toujours été en dessous des deux précités... mais ça s'améliore, les temps changent

      • [^] # Re: Oh oui !

        Posté par  . Évalué à 4.

        Au même niveau qu'Oracle? Pour quels types de requêtes? select simple, select imbriqué, avec un not Null, avec un outer join? Ou tu parles des insert et des updates? Ah oui, mais en gérant la transaction? Et comment? d'où vient ton affirmation?

        Je ne dis pas cela "pour" Oracle (ou db2, ou autre) mais juste pour dire qu'ils ne boxent pas dans la même catégorie.

        J'utilise beaucoup mysql, même si je préfère postGres, beaucoup de choses tournent à l'origine sur mysql. Ex: rails, il faut rajouter des trucs pour faire tourner postgres.
        J'aime bien mysql: léger, simple, pratique grâce à l'excellent phpmyadmin, portable (je parle de la base, pas du sql, mais là, je suis dans le cas de Traumat : je m'abstrais de la base)

        ...Mais je n'utilise pas mysql pour tout... Pour un site petit/moyen, en lecture seule, sans transaction, sans souci quoi... (>>50% des sites) ok pour mysql. Pour les autres cas, désolé...on ne grimpe pas le Mont Blanc en espadrilles (et j'aime beaucoup les espadrilles)

        • [^] # Re: Oh oui !

          Posté par  . Évalué à 3.

          il me semble que j'avais vu ça dans eWeek il y a quelques années...

          Maintenant, je n'ai jamais parlé de transactionnel (à l'époque où j'avais vu ça, c'était encore en beta dans mysql), je parlais plutôt de l'usage standard backend web... si c'est pour du vrai transactionnel, je ne risquerais pas ma tête avec mysql.

          Donc oui, ce n'est pas la même catégorie (enfin mysql avance petit à petit, donc petit à petit, il va y avoir des bobos dans la comparaison), mais bon, si on prend le plus petit dénominateur commun pour les test, la comparaison a un sens.

      • [^] # Re: Oh oui !

        Posté par  (site web personnel) . Évalué à 3.

        > question perfs pures, mysql est au même niveau qu'oracle

        Je croyait qu'il était interdit de faire des benchmarks d'Oracle ?

        • [^] # Re: Oh oui !

          Posté par  . Évalué à 2.

          en effet, il me semble aussi, mais en tout cas, le bench que j'ai vu existe, je l'ai retrouvé: c'était orecle vs mysql vs mssql via jdbc... sur eweek

        • [^] # Re: Oh oui !

          Posté par  . Évalué à 0.

          Si c'est interdit, c'est une clause abusive, et donc ça n'est pas interdit.

          • [^] # Re: Oh oui !

            Posté par  (site web personnel) . Évalué à 1.

            > Si c'est interdit, c'est une clause abusive, et donc ça n'est pas interdit.

            Tu tests les avocats d'Oracle pour nous quand alors ?

            • [^] # Re: Oh oui !

              Posté par  . Évalué à 1.

              J'ai confiance en la justice de mon pays...

              Ouais quoique.

            • [^] # Re: Oh oui !

              Posté par  . Évalué à 2.

              Et après les avocats, il faudra aussi gérer les commerciaux qui deviendront tout de suite bien moins conciliants sur les tarifs ...

              BeOS le faisait il y a 20 ans !

        • [^] # licence d'utilisation

          Posté par  (site web personnel) . Évalué à 1.

          la licence d'utilisation que tu es obligé d'approuver quand tu installes le logiciel t'oblige à demander l'accord d'Oracle avant de publier des résultats de performance. histoire sans doute de rectifier le tir si nécessaire ;-) plus sérieusement, les gens d'Oracle m'ont précisé que c'était pour éviter des comparaisons basées sur des mauvaises installations comme par exemple, la base sur un RAID5

  • # MySQL 5.0 est sorti

    Posté par  . Évalué à 1.

    Une bonne nouvelle! Encore 2 formats de tables supplémentaires, histoire d'embrouiller encore un peu plus les personnes qui veulent l'utiliser... M'enfin, ne crachons pas dans la soupe, ça apporte enfin (ne pas se moquer) les vues et les procédures stockées.

    Toujours pas de contrainte d'intégrité cependant, les développeurs vont pouvoir continuer a développer des applications goraytes sans que les DBAs aient leur mot à dire, que du bonheur.

    • [^] # Re: MySQL 5.0 est sorti

      Posté par  . Évalué à 3.

      les personnes qui veulent utiliser mysql ne sont pas non plus obligés d'utiliser ces tables.

      D'ailleurs, je doute que toutes les personnes qui utilisent un sgbdr (que ce soit mysql, oracle ou autres) connaissent l'exhaustivité de ses fonctionnalités...

      on peut pas se plaindre d'un coté qu'il manque certaines fonctions, et cracher dans la soupe quand certaines apparaissent.

      Apres, les fonctionnalités à developper en priorité, c'est tout une histoire...

  • # Que de temps pour les vues ...

    Posté par  (site web personnel) . É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 ?

    http://about.me/straumat

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

      Posté par  . É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  (site web personnel) . Évalué à 2.

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

        http://about.me/straumat

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

          Posté par  (site web personnel) . É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 ?

          http://about.me/straumat

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

            Posté par  (site web personnel) . É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  . É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  . É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  . É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  . É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  (site web personnel) . Évalué à 2.

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

              Bretelles et ceintures comme dirait un collègue.

              L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

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

                Posté par  . É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  . É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  (site web personnel) . Évalué à 7.

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

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

                  L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

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

      Posté par  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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

        http://about.me/straumat

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

          Posté par  (site web personnel) . É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  . É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  . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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?

  • # Licence

    Posté par  . Évalué à 1.

    Bonjour à tous,
    C'est une super bonne nouvelle mais j'ai toujours rien compris à l'histoire des licences.
    Je suis developpeur de site web, que je vend à mes client et que j'heberge sur un serveur apache/mysql.
    Dois-je fournir les sources de mon site pour pas payer la licence ?

    • [^] # Re: Licence

      Posté par  (site web personnel) . Évalué à 2.

      De ce que j'ai compris :
      A tes clients :
      - oui si le site web est dependant de la base.
      - non si tu proposes juste une fonctionnalité MySQL a tes clients. (c'est pas lié, donc pas de pb GPL)

      A tes visiteurs des sites : non.

    • [^] # Re: Licence

      Posté par  . Évalué à 2.

      Non, puisque (je suppose) tu ne fais pas de modification à Mysql!
      C'est le logiciel mysql lui même qui est sous une licence qui oblige à donner les sources. Ta partie web, c'est juste des données, utilisée par apache et mysql.
      Et un logicil ne peut forcer de licence sur le contenu produit (sauf s'il intègre son propre code dans le produit, genre un compilo).

      • [^] # Re: Licence

        Posté par  . Évalué à 2.

        Merci, je comprend mieux.
        Là où j'avais un doute c'est que je considere un site comme une appli.
        Mais c'est vrai que mes sites se servent de MYSQL sans en dependre, et sans à avoir besoin de modifier MYSQL.
        Cette licence s'applique si je créé une appli qui m'oblige à adapter MYSQL à son fonctionnement.

    • [^] # Re: Licence

      Posté par  (site web personnel) . Évalué à 3.

      En fait, le cas MySQL est plus compliqué que ce que les commentaires précédents ont bien pu indiquer, surtout pour du web.

      Si tu héberges le service et que le client n'a accès à l'application que par l'interface web, tu n'as pas à fournir quoi que ce soit, car tu fournis un service et non un logiciel (bon, sauf cas de GPLv3, en fait).

      Autrement, cela dépends de l'interface que tu utilises pour accèder à la base de données. Si tu linkes à un moment donné avec la bibliothèque mysqlclient, qui est GPL, donc ton code est contaminé par le côté GPL et doit donc être GPL. (mais après, on retombe sur la GPL qui dit que si tu fournis du binaire, tu dois fournir le source, cf paragraphe précédent). Si tu as une autre bibliothèque, cela dépends de celle-ci. Et après, c'est maltraiter des drosophiles (par exemple, en Java, utiliser l'interface JDBC avec MySQL est ambigu, car le driver JDBC MySQL est GPL mais on n'utilise pas son interface donc pas de dépendance forte).

      seb.

      • [^] # Re: Licence - JDBC GPL , LGPL .... bref, c'est le bordel.

        Posté par  . Évalué à 0.

        Pour le cas de Java, c'est assez marrant et même extrement complexe.

        En fait, les drivers JDBC JConnecteur 2.0.x sont sous license LGPL. Tu peux quasiment les utiliser comme tu veux.
        Ces drivers fonctionnent encore avec MySql 4.0 pour les nouvelles, j'ai jamais testé

        Par contre les drivers JDBC JConnecteur 3.0.x, ils sont en GPL et il sont bien meilleur, supporte JTA et tout un tas d'autres trucs de J2EE.

        Et c'est là que çà devient problematique même pour un développeur de logiciel libre et un utilisateur de logiciel libre.

        La GPL n'est pas compatible avec toutes les licenses de logiciels libres.

        Par exemple, Open Office 2.0 recommande d'utiliser JConnector 2.0.x dans sa documentation pour Open Base même si les JConnector 3.0.x fonctionne parfaitement. Mais vu que la GPL n'est pas compatible avec la licence d'Open Office, il ne peuve pas recommandé officielement d'utiliser des drivers en GPL :p.

        Si tu veux les drivers JDBC pour un DataSource de Tomcat en théorie , tu n'as pas le droit car la license Apache n'est pas compatible avec la GPL.
        Par exemple, si le développeur a développé une appli web avec Hibernate (middleware gérant la persistance dans une base de données) et une base Oracle.

        Et que toi, tu récupères son appli que tu la fasses fonctionner avec un MySql et les drivers JConnector 3.0.x. Tu seras dans l'ilégalité :o).

        • [^] # Re: Licence - JDBC GPL , LGPL .... bref, c'est le bordel.

          Posté par  . Évalué à 4.

          C'est pas LGPL la licence d'OOo ? Il me semble avoir lu ça dans l' "EULA" d'OOo 2.0 que j'ai installé tout à l'heure.

          BeOS le faisait il y a 20 ans !

          • [^] # Re: Licence - JDBC GPL , LGPL .... bref, c'est le bordel.

            Posté par  . Évalué à 0.

            Tu as raison. C'est bien LGPL la license d'OpenOffice.

            Enfin, çà ne change rien au problème.

            Tu ne peux pas linker un programme LGPL avec un programme GPL ! Sauf, si tu detiens le copyright sur le programme en GPL dans ce cas, tu diffuse une partie du code sous license LGPL pour permettre aux utilisateurs de greffer des modules sous une autre license.

            • [^] # Re: Licence - JDBC GPL , LGPL .... bref, c'est le bordel.

              Posté par  . Évalué à 2.

              Tu ne peux pas linker un programme LGPL avec un programme GPL ! Sauf, si tu detiens le copyright sur le programme en GPL dans ce cas, tu diffuse une partie du code sous license LGPL pour permettre aux utilisateurs de greffer des modules sous une autre license.

              N'importe quoi ! Non seulement tu peux lier du code GNU GPL a du code GNU LGPL, mais en plus tu peux les lier statiquement.

              http://www.gnu.org/philosophy/license-list.html#GPLCompatibl(...)
              « GNU Lesser General Public License, or GNU LGPL for short.
              [...] It is compatible with the GNU GPL. »

              http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible
              « What does it mean to say a license is "compatible with the GPL".
              It means that the other license and the GNU GPL are compatible ; you can combine code released under the other license with code released under the GNU GPL in one larger program. »

  • # MySql 5.0 = Oracle 6.0 ?

    Posté par  . Évalué à 3.

    MySql va se hisser à la hauteur d'oracle ??? Oui de la version Oracle 6.0 alors. On ne se rend pas compte tout ce qu'il y a dans Oracle, il ne suffit pas d'avoir les triggers pour s'y comparer.

    Même Postgresql qui est l'une des meilleurs db libres pour les fonctionnalités SQL n'y arrive pas encore et pourtant cela fait des années qu'elle a les procédures stockées (perl,sql ou python), les triggers les vues et les subqueries, les rules, groupes et autres.

    • [^] # Re: MySql 5.0 = Oracle 6.0 ?

      Posté par  (site web personnel) . Évalué à 7.

      > On ne se rend pas compte tout ce qu'il y a dans Oracle, il ne suffit pas d'avoir les triggers pour s'y comparer.
      C'est bien le problème, on ne compte plus les services informatiques qui payent très cher une licence Oracle pour ne pas se rendre compte de ce qu'ils ont acheté. Et comme ils ne savent pas que ça existe ils ne s'en servent pas. C'est comme ça.

      Un nombre conséquent d'applications basées sur Oracle *n'utilisent pas* les fonctionnalités avancées d'Oracle, qui est là juste pour garantir que le siège du DSI n'est pas éjectable, car c'est un poids lourd du "marché". AMHA il n'est pas urgentissime que PostGreSQL ou MySQL fassent la course à la fonctionnalité avec Oracle, le marché des applications auxquelles PostGreSQL et MySQL peuvent répondre en termes de fonctionnalités est énorme. Après faut vendre et donner confiance, mais c'est une autre histoire, et ça n'a plus rien à voir avec la technique 8-)

    • [^] # Re: MySql 5.0 = Oracle 6.0 ?

      Posté par  (site web personnel) . Évalué à 2.

      A choisir entre une db gratuite qui fait ce dont j'ai besoin (aller vite dans le petites requete) et un db très chere qui fait ce dont j'ai besoin + plein de chose que j'ai pas besoin, je prend la db gratuite...

      Combien de base Oracle installée qu'on pourrait remplacer par MySQL de facon transparente (sans que l'utilisateur s'en apercoive, sans limitations dans ses possibilités)? Beaucoup...

      • [^] # Re: MySql 5.0 = Oracle 6.0 ?

        Posté par  . Évalué à 6.

        On est tous d'accord là dessus, mais dire que MySQL est au niveau d'Oracle ou SQL Server, c'est du mensonge.
        Il a un niveau de maturité et de fonctionnalités techniques pour être suffisant dans 70% des cas (chiffre au pif), maintenant pour les 30% restant, c'est pas MySQL que je choisirai.

      • [^] # Re: MySql 5.0 = Oracle 6.0 ?

        Posté par  . Évalué à 3.

        Le problème c'est que le jour où mysql ou postgres se vautreront (que ce soit en terme de bugs ou de perfs), le dsi regrettera de ne pas s'etre appuyé sur oracle.

        Je ne dis pas qu'Oracle est infaillible, mais quand on doit rendre des comptes, avoir l'option "j'utilise le meilleur SGBD du marché", ça aide. Un DSI ne pourra jamais se faire reprocher d'avoir choisi oracle (sauf sur le cout). Par contre, en cas de problèmes, ce raisonnement ne tiendra pas vis à vis de sgbdr libres.

        C'est con, stupide, car bon nombre de solutions libres sont fiables, mais la frilosité, la peur pousse les gens à opter vers des solutions surdimensionnées par rapport à leur besoin, mais qui leur permette comme dit plus haut de sauver leur place...

        (et non je ne fais pas de pub pour oracle)Le problème c'est que le jour où mysql ou postgres se vautreront (que ec soit en terme de bugs, ou de prfs), le dsi regretera de ne pas s'etre appuyé sur oracle.

        Je ne dis pas qu'Oracle est infaillible, mais quand on doit rendre des comptes, avoir l'option "j'utilise le meilleur SGBD du marché", ça aide. Un DSI ne pourra jamais se faire reprocher d'avoir choisi oracle (sauf sur le cout). Par contre, en cas de problèmes, ce raisonnement ne tiendra pas vis à vis de sgbdr libres.

        C'est con, stupide, car bon nombre de solutions libres sont fiables, mais la frilosité, la peur pousse les gens à opter vers des solutions surdimensionnées par rapport à leur besoin, mais qui leur permettent comme dit plus haut de sauver leur place...

      • [^] # Re: MySql 5.0 = Oracle 6.0 ?

        Posté par  . Évalué à 7.

        Combien de base Oracle installée qu'on pourrait remplacer par MySQL de facon transparente (sans que l'utilisateur s'en apercoive, sans limitations dans ses possibilités)? Beaucoup...


        Non la bonne réponse est très peu ;-)
        Au travail, il y a eu une évaluation pour remplacer Oracle et avoir une db libre, le choix s'est porté sur Postgresql 8.0 pour moins de 70% des applications, MySql même pas 1 % : toutes les instances (+/- 800 bases de données) utilisent triggers et sql embarqué. Peut-être que la version 5 de MySql fera un meilleur score.

      • [^] # Pour remplacer Oracle ...

        Posté par  . Évalué à 2.

        Le dernier MySQL se rapproche effectivement de la compatibilité Oracle, mais il y a encore de la marge.


        Personellement, si tu veux remplacer tes base Oracle par une solution libre, je te conseille Firebird et le module Fyracle http://www.janus-software.com/fb_fyracle.html

        Firebird est une base opensource sous license dérivée de la MPL, donc plutôt généreuse ...

        Son gros avantage est de disposé de tonnes de fonctionalités : transations avancées, triggers, procedures stockées, unicode ... et tout ça fonctionant sous les principaux OS.

        Fyracle est un ensemble de scripts/procedures et diverses améliorations qui va se greffer sur Firebird et permet à une immence partie du code Oracle de fonctionner directement sans modification !

        Pour preuve, Fyracle permet de faire tourner Compiere http://www.compiere.org/ le célèbre outil ERP + CRM opensource sous MPL qui ne marchait que sous Oracle !!! Vraiment impressionant comme réussite.

        Je ne m'explique clairement pas pourquoi MySQL a pendant si longtemps dominé le marché des bases libre étant donné son manque de fonctionalité chronique.... mais finalement tout vient à point qui sait attendre on a enfin les views sous MySQL .... sauf que perso, je les ait sous Firebird depuis plus de 5 ans ;-)

        Si vous ne connaissez pas cette base fort sympatique, je vous invite à suivre http://www.firebird-fr.eu.org/

Suivre le flux des commentaires

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