MySQL 4.1 disponible!

Posté par  (site web personnel) . Modéré par kalahann.
Étiquettes : aucune
0
24
jan.
2003
PHP
Vu sur www.nexen.net :


ca y est, MySQL 4.1 est désormais disponible au téléchargement. Comme d'habitude, elle est exempte de tout bug connu. Cette version inclut de nombreuses avancées majeures, attendues depuis longtemps par les utilisateurs :
+ support des sous-requêtes (requêtes imbriquées),
+ support complet des transactions,
+ support de l'Unicode,
+ clé étrangères,
+ Amélioration de la sécurité (SSL)




C'est toutefois une version pour les développeurs.

Aller plus loin

  • # Re: MySQL 4.1 disponible!

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

    \O/

    Enfin le support pour les sous-requetes !
    Chouette !!!

    Enfin je ne suis pas particulièrement développeur mais cette version devrait me (nous) simplifier la vie.

    M.

    • [^] # Re: MySQL 4.1 disponible!

      Posté par  . Évalué à 7.

      Enfin le support pour les sous-requetes !
      Chouette !!!

      Oui, enfin, parce que c'est quand meme une fonctionnalité extremement importante... Je suis tombé des nues quand je me suis rendu compte, par la pratique, que ces requetes imbriquées n'étaient pas possibles...

      • [^] # Re: MySQL 4.1 disponible!

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

        Oui enfin tu peux l'attendre ta 4.1, personne en prod (chez les hébergeurs en particulier) utilisent la 4.0 donc tu peux attendre minimum un an avant qu'elle arrive (si la 4.0 arrive déjà avant)
        Et ils disent déjà préparer la 5.0 pour fin 2003 avec des procédures stockées et les triggers

        Menfin bon .. On peut se débrouiller la plupart du temps sans les procédures stockées avec les LEFT JOIN ...

        • [^] # Re: MySQL 4.1 disponible!

          Posté par  . Évalué à 3.

          La 4.0 est parfaitement utilisable en prod depuis au moins la 4.0.4 (c'en est à la 4.0.9). Elle est étiquetée "gamma" ce qui correspond à quelque chose de très stable chez MySQL. Par contre la 4.1 est effectivement balbutiante.

          Les hébergeurs ont d'ailleurs pas mal à gagner avec la 4.0, qui introduit un cache de requêtes très utile avec les grosses bouses genre phpNuke.

          • [^] # Re: MySQL 4.1 disponible!

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

            Cite moi tous les hébergeurs qui utilisent la 4.0.x
            Je suis intéressé de voir si je me suis trompé ;)

            • [^] # Re: MySQL 4.1 disponible!

              Posté par  . Évalué à 4.

              Je ne vois pas le rapport. Il y a des tas de gens qui utilisent MySQL sans être hébergeurs.

              Tu peux aussi faire des stats sur les versions de PHP et d'Apache installées par les hébergeurs, et en déduire que PHP 4.3 et Apache 2 sont inutilisables en production... Ou d'autres foutaises du même genre ;) Par contre, si tu as des arguments constructifs pour dissuader l'utilisation de MySQL 4 en prod, tu es le bienvenu. Personnellement j'ai essuyé un bug chiant avec OPTIMIZE TABLE (4.0.4), mais c'est tout.

              (pour répondre à ta question, altern.com se prépare à migrer en 4.0.x (depuis la 3.22 ;-)), et OVH s'y intéresse aussi. Mais c'est une discussion spécieuse).

              • [^] # Re: MySQL 4.1 disponible!

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

                Ah altern un grand nom, de grands souvenirs, c'est avec lui que j'ai commencé ! ;)
                C'est sur que si ovh passe en 4.0.x je retire ce que j'ai dit
                Mais sérieusement, les hébergeurs ne peuvent pas faire n'importe quoi, ils sont en fait un indicateur de ce qui est stable
                (Chuis préssé je peux pas en dire plus ;o)

              • [^] # Re: MySQL 4.1 disponible!

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

                http://www.mysql.com/downloads/index.html(...)

                # MySQL 3.23 -- Production release (recommended)
                # MySQL 4.0 -- Gamma release (use this for new development)
                # MySQL 4.1 -- Alpha release (use this for previewing and testing new features)

    • [^] # Re: MySQL 4.1 disponible!

      Posté par  . Évalué à 4.

      Sans parler des clés étrangères. On pouvait se débrouiller en bidouillant, mais pour avoir un modèle de données propre, c'était pas l'idéal.
      Cela dit, il y a aussi PosgreSQL, aussi.

    • [^] # Re: MySQL 4.1 disponible!

      Posté par  . Évalué à 7.

      Il est a noter que, si les sous-requetes sont pratiques (ainsi que les DELETE/UPDATE avec des criteres de selections sur plusieurs tables), c'est souvent une <B>mauvaise</B> idée de s'en servir notamment parce que leur implementation consiste souvent a creer une table temporaire pour le resultat de la sous-requete. La taille de la table temporaire va souvent determiner la vitesse de la requete et helas, les possibilites d'optimisation sont beaucoup plus faible. Exemple : Trouver les entrees d'une table non presente dans une autre : SELECT table1.* FROM table1 WHERE table1.id NOT IN (SELECT DISTINCT id FROM table2); Si l'ecriture est immediate, il suffit de reflechir 3 secondes pour imaginer le resultat si le nombre de lignes dans les tables se compte par milliers. Il est beaucoup plus utile de faire une jointure comme par exemple : SELECT table1.* FROM table1 LEFT JOIN table2 USING (id) WHERE table2.id IS NULL;

      • [^] # Re: MySQL 4.1 disponible!

        Posté par  . Évalué à -1.

        Oui, mais... justement. Les jointures, on peut les faire maintenant sous MySQL ? Mon souvenir (date de mars 2002) me rappelle que ça n'était pas possible (où alors j'étais vraiment neuneu, mais...) ?

        • [^] # Re: MySQL 4.1 disponible!

          Posté par  . Évalué à 3.

          J'utilise une requete equivalente (avec le LEFT JOIN) avec un serveur en 3.22.32 (qui date de 2000). En revanche, je ne connais pas l'historique des autres types de jointure (INNER, RIGHT), il est possible qu'elle n'ait pas ete utilisable avant les 3.23.x

        • [^] # Re: MySQL 4.1 disponible!

          Posté par  . Évalué à 2.

          Mon souvenir (date de mars 2002) me rappelle que ça n'était pas possible (où alors j'étais vraiment neuneu, mais...) Mais non, tu n'étais pas neuneu, juste mal réveillé ;-))

        • [^] # Re: MySQL 4.1 disponible!

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

          Les jointures on peut les faire depuis toujours (vu qu'un simple where table.col = table2.col en est une), c'est le principe même d'un SGBD
          Maintenant, les clés étrangères avec les controles ne sont là que depuis la 4.0

      • [^] # Re: MySQL 4.1 disponible!

        Posté par  . Évalué à 2.

        Certes, ton exemple est parlant. Mais inversement, si la sous-requête renvoit peu d'enregistrement car très discriminate (clause where), alors là on y gagne vraiment en efficacité. De toute façon, il souvent tester et adopter l'une ou l'autre des méthodes (sub-select ou jointure) car cela dépend beaucoup des cas ainsi que des SGBD. C'est donc une très bonne nouvelle que cette fonctionnalité soit présente car elle s'avère quand même assez indispensable

  • # Re: MySQL 4.1 disponible!

    Posté par  . Évalué à 9.

    Attention c'est une alpha release (use this for previewing and testing new features)(use this for previewing and testing new features)

  • # Troll

    Posté par  . Évalué à 6.

    Ouaiiis, ça y est, MySQL commence à faire une partie de ce que PostgreSQL sait faire depuis longtemps...

    [-1]

  • # Question stupide

    Posté par  . Évalué à 4.

    J'entends toujours dire que Postgres est supérieu à MySQL. Si c'est vrai, pourquoi dit-on toujours du trio Apache/PHP/MySQL qu'il est si génial ? Pourquoi pas le trio Apache/PHP/Postgres ? Est-ce que Postgres a des problèmes avec PHP ? Est-ce un roblème de licence ?

    • [^] # Re: Question stupide

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

      Mysql est souvent plus rapide (ca dépend des insctructions) et stable, mais il est à noter que pgsql devient de plus en plus rapide et stable et mysql dispose de plus en plus de fonctionnalités
      On peut donc dire qu'ils vont vers le même point

      • [^] # Re: Question stupide

        Posté par  . Évalué à 2.

        euh niveau fonctionnalité c'est plutôt l'inverse non ?

        • [^] # Re: Question stupide

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

          Oui mais AMHA chacun évolue dans le sens de l'autre

          • [^] # Re: Question stupide

            Posté par  . Évalué à 1.

            je crains d'avoir un doute sur la tournure de ta phrase (nan je suis pas encore alcoolisé mais ça va pas tardé ^^), tu voudrais dire que :

            MySQL -> + de fontionalités ?
            PSQL -> + de rapidité ?

            Autant pour héberger un forum @lakon du type PHPBB MYSQL est assez rapide je sais pas si dans un cas de figure plus stressant ça surpasserais psql....bon qui me file un gros serveur bien fréquenté pour tester ? :)

      • [^] # Re: Question stupide

        Posté par  . Évalué à 5.

        Mysql est souvent plus rapide (ca dépend des insctructions) et stable, mais il est à noter que pgsql devient de plus en plus rapide et stable et mysql dispose de plus en plus de fonctionnalités.
        On peut donc dire qu'ils vont vers le même point.

        MySQL est souvent plus rapide, mais en cas de requêtes complexes, Postgresql est supérieur (il a un optimiseur complexe, et même un mode par algo génétique pour les requêtes vraiment complexes). De plus, si on ajoute tout ce que peut faire Postgres "tout seul" : triggers, procédures stockées, contrôle d'intégrité (foreign keys), il est beaucoup plus puissant.

        Question stabilité, je n'ai jamais planté Postgres (ainsi qu'un ami qui en a sur ses serveurs en production); alors que MySQL a eu la réputation d'être plantable (d'où les outils de récupération de table ISAM).

        Je crois qu'une grosse amélioration qui a été apportée à Postgres, c'est le "vacuum" sans verrouillage de table. Le vacuum effectue une sorte de défragmentation, et jusqu'à un version récente, il revenait à rendre la base plus ou moins inutilisable, ce qui est un problème si la base doit fonctionner 24h/24. Le vacuum ("vide" en anglais) réduit la taille des fichiers de la base (élimine les trous).

        La fragmentation est dûe au modèle de MVCC = Multi-Version Concurrency Control, qui permet l'isolation des transactions, ce qui veut dire qu'on peut être plusieurs à modifier la base en même temps et chacun ne voit que ses modifs, tant que ce n'est pas "commité". La fragmentation sera d'autant plus forte qu'il y aura des mise à jour (update), bien entendu si on fait surtout des select, la fragmentation sera faible. Je ne sais pas s'il est forcément nécessaire de faire des vacuum souvent, il faudrait mesurer l'impact sur les performances.

      • [^] # Re: Question stupide

        Posté par  . Évalué à 3.

        On peut dire aussi que MySQL est à la mode :))

        plus sérieusement, je pense que mysqladmin a fait beaucoup pour sa popularité, permettant aux hébergeurs de proposer un outil simple pour le quidam et sa page perso.

    • [^] # Re: Question stupide

      Posté par  . Évalué à 3.

      J'entends toujours dire que Postgres est supérieur à MySQL. Si c'est vrai, pourquoi dit-on toujours du trio Apache/PHP/MySQL qu'il est si génial ? Pourquoi pas le trio Apache/PHP/Postgres ?

      Il y a plusieurs raisons à la popularité de MySQL :
      - il a commencé comme un moteur tout simple et a été adopté très tôt par des sites Web pour rajouter du dynamique
      - il y a une société derrière, qui aide à le promouvoir, ça compte (dès qu'il y a une nouvelle version, c'est repris sur pas mal de sites Web)
      - dans le temps, MySQL était beaucoup plus rapide pour des requêtes simples comme celles d'un site Web. Je ne sais pas si ce surcroît de rapidité est toujours nécessaire (comme pour une carte graphique, atteindre 220 fps c'est pas vraiment utile).

      J'utilise Apache/PHP/Postgres depuis 2 ans, et ça marche très bien. Je pense que si on veut une base de données pour stocker des choses vraiment importantes, Postgres est indispensable car il gère parfaitement les transactions et la cohérence (avec les clefs étrangères), ce que ne fait pas encore MySQL. Historiquement, Postgres se comporte très bien avec un grand nombre de connexions simultanées.

      J'ai tout récemment voulu tester les différentes version de Postgres (par exemple la dernière 7.3 par rapport à la 7.0), j'ai utilisé pgbench qui est livré avec et qui simule plus ou moins un TCP-B (c'est ce qui est écrit). C'est un benchmark assez basique, qui ne remplace pas votre test pour votre besoin. A première vue, il n'y a pas de différence très significative, mais il faudrait que je refasse les tests plus rigoureusement (j'ai déjà utilisé une partition formatée avant chaque test). pgbench simule plusieurs clients en parallèle.

      J'ai aussi voulu faire la comparaison Postgres 7.3.1 contre MySQL 3.23.54 (dernières versions), en portant pgbench sur MySQL. Effectivement, en utilisant des tables simples (MyISAM) et sans transactions (pgbench fait "begin; select; update; [...] ; end"), MySQL est 2 à 3 fois plus rapide. Par contre, dès que j'utilise des tables InnoDB, les performances baissent très nettement. En fait, je n'ai pas réussi à reproduire le test de pgbench car MySQL bloque lors de 2 updates simultanés sur la même rangée (deadlock).

      J'ai aussi testé les procédures stockées de Postgres (toujours avec pgbench) et ça accélère énormément : selon les paramètres, entre 2 et 4 fois.

      • [^] # Re: Question stupide

        Posté par  . Évalué à 1.

        - dans le temps, MySQL était beaucoup plus rapide pour des requêtes simples comme celles d'un site Web. Je ne sais pas si ce surcroît de rapidité est toujours nécessaire (comme pour une carte graphique, atteindre 220 fps c'est pas vraiment utile).

        Il n'y a pas que le Web dans la vie. Je peux te dire que quand on stocke des événements en temps réel, on est bien content de tirer parti de la rapidité de MySQL...

        • [^] # Re: Question stupide

          Posté par  . Évalué à 1.

          Je peux te dire que quand on stocke des événements en temps réel, on est bien content de tirer parti de la rapidité de MySQL...

          J'imagine que tu parles d'expérience, tu peux en dire plus sur tes besoins ? As-tu comparé MySQL et PostgreSQL pour ton utilisation ? N'hésite pas, tout retour d'information est intéressant.

  • # Re: MySQL 4.1 disponible!

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

    "Comme d'habitude, elle est exempte de tout bug connu"
    Ben c'est normal non ?

    Y'a guère que MS qui lance un logiciel sans en avoir corrigé les bugs

    https://damien.pobel.fr

  • # Re: MySQL 4.1 disponible!

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

    Installer MySQL... voilà une manière de lutter efficacement contre les DDOS causés par MSSQL... :)

    Je pense que PostGreSQL est néanmoins plus appréciable pour les DB business : employés, clients, etc... et les gros projets, pas forcément Web, il y a aussi des giga-projets internes dans les grosses sociétés. Pensez à la gestion des trains ou des avions, par exemple : vous feriez plus confiance à une DB qui gère les transactions et l'intégrité ou à MySQL ?

Suivre le flux des commentaires

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