Tant que le plugin binaire est écrit de manière à être compilable sur de multiples plateformes, et que son code source est ouvert, je ne vois malheureusement pas ce qui freinera Google à le faire, notamment si ça concerne le domaine des jeux, où la performance est reine… Un programme compilé sera toujours 10/100/1000 fois plus rapide qu'un programme interprété ou "pseudo"-compilé.
Mais je te rejoins sur le fait que tout ceci n'est qu'une utopie, et l'on reviendra (très probablement) au bon vieux concept d'ActiveX propriétaire… ;-(
MySQL est aussi totalement incapable de gérer les schémas.
CREATE SCHEMA foo passe sans soucis… mais créé une base de données foo au lieu d'un schéma.
En effet d'après la doc : CREATE SCHEMA is a synonym for CREATE DATABASE !
Il est donc impossible d'avoir 2 schémas portant le même nom dans 2 bases de données différentes… Ce qui enlève tout intérêt à leur utilisation !
Oui, et c'est bien normal, puisque une base de données au sens de MySQL n'est rien d'autre qu'un schéma au sens "classique" SQL (il n'y a qu'à regarder "information_schema")… MySQL n'est donc en fait qu'un serveur monobase, où les schémas sont vus par l'utilisateur comme une base de données.
Mais quand on me dit que MySQL est rapide, je rigole bien fort… Sur des requêtes un temps soit peu compliquées, à données strictement équivalentes, j'ai déjà obtenu un rapport de 70 entre PostgreSQL et MySQL.
Et il est vrai que MySQL pêche par un certain nombre de lacunes/faiblesses/illogismes :
absence de contraintes de vérification
absence de séquences indépendantes des tables
limitation du nombre de triggers à 6 par table
longueur de la liste des contraintes inhérentes à l'utilisation des triggers plus longue que celle des fonctionnalités desdits triggers
impossibilité de faire des transactions sur des table MyISAM / impossibilité de faire de la recherche Fulltext sur des tables InnoDB
complexité des procédures stockées pour renvoyer un ensemble de résultats
aberration dans la souplesse d'utilisation du GROUP BY
absence de fonctions basiques mais néanmoins vitales (notamment en terme de fonctionnalité de synchronisation) telles que la gestion des microsecondes
impossibilité de désactiver ponctuellement un trigger
gestion des types ENUM et SET
… j'en oublie probablement
Je rejoins néanmoins ce qui a été dit plus haut : MySQL est populaire depuis sa version 3.23, et du fait que les hébergeurs n'ont eu cesse de le proposer de manière quasi-exclusive.
Le problème aujourd'hui, c'est qu'une grande majorité de développeurs web (notamment ceux qui font du PHP) ne connaissent rien d'autre, et ont pris tellement de mauvaises habitudes avec que toute autre base qui ne fait pas comme MySQL est anormale… Et ne parlez surtout pas à ces gens là de transaction, d'intégrité, de cohérence ou d'intégration multi-applicative…
Bref, si MySQL était plutôt un bon choix il y a quelques années, c'est malheureusement aujourd'hui un choix par défaut non motivé, mais qui convient malheureusement parfaitement au gens qui développent au pied levé et n'ont pas envie de s'ennuyer avec une base de données fortement typée.
[^] # Re: Google fait de l'ouvert et du ferme aussi
Posté par Erika31 . En réponse à la dépêche Sergey Brin dénonce les « cages dorées » de Facebook et Apple. Évalué à 2.
Tant que le plugin binaire est écrit de manière à être compilable sur de multiples plateformes, et que son code source est ouvert, je ne vois malheureusement pas ce qui freinera Google à le faire, notamment si ça concerne le domaine des jeux, où la performance est reine… Un programme compilé sera toujours 10/100/1000 fois plus rapide qu'un programme interprété ou "pseudo"-compilé.
Mais je te rejoins sur le fait que tout ceci n'est qu'une utopie, et l'on reviendra (très probablement) au bon vieux concept d'ActiveX propriétaire… ;-(
[^] # Re: Quitte à rester dans le gore
Posté par Erika31 . En réponse au journal MySQL est une bouse immonde. Évalué à 1.
Oui, et c'est bien normal, puisque une base de données au sens de MySQL n'est rien d'autre qu'un schéma au sens "classique" SQL (il n'y a qu'à regarder "information_schema")… MySQL n'est donc en fait qu'un serveur monobase, où les schémas sont vus par l'utilisateur comme une base de données.
Mais quand on me dit que MySQL est rapide, je rigole bien fort… Sur des requêtes un temps soit peu compliquées, à données strictement équivalentes, j'ai déjà obtenu un rapport de 70 entre PostgreSQL et MySQL.
Et il est vrai que MySQL pêche par un certain nombre de lacunes/faiblesses/illogismes :
Je rejoins néanmoins ce qui a été dit plus haut : MySQL est populaire depuis sa version 3.23, et du fait que les hébergeurs n'ont eu cesse de le proposer de manière quasi-exclusive.
Le problème aujourd'hui, c'est qu'une grande majorité de développeurs web (notamment ceux qui font du PHP) ne connaissent rien d'autre, et ont pris tellement de mauvaises habitudes avec que toute autre base qui ne fait pas comme MySQL est anormale… Et ne parlez surtout pas à ces gens là de transaction, d'intégrité, de cohérence ou d'intégration multi-applicative…
Bref, si MySQL était plutôt un bon choix il y a quelques années, c'est malheureusement aujourd'hui un choix par défaut non motivé, mais qui convient malheureusement parfaitement au gens qui développent au pied levé et n'ont pas envie de s'ennuyer avec une base de données fortement typée.
Vive PostgreSQL ;-)