Petit sondage php/mysql/posgresql
Par Laurentj le mardi, avril 22 2008, 17:17 - Technologies Web - Lien permanent
Ce qu'il y a bien dans Mysql 5, c'est qu'on peut enfin commencer à utiliser triggers, procédures stockées et vues. Ça permet d'alléger le code PHP des applis web, et de garder une meilleure cohérence dans les données (et de meilleurs perfs dans le traitement des données je pense).
Bref, j'aimerai bien commencer à pouvoir faire des vrais schemas de bases de données dans les applis web (et dans certaines briques de jelix), quand je n'ai que mysql sous la main.
Seulement voilà, je ne suis pas sûr que Mysql 5 soit dispo chez tout les hébergeurs. Aussi, si vous pouviez me dire les versions de mysql, php, et posgresql que propose votre hébergeur (en donnant son nom), ce serait sympa :-)
Attention, n'allait pas seulement voir dans le phpmyadmin de votre hébergement. En effet, par exemple, je sais qu'OVH propose depuis peu du mysql 5, mais seulement pour les nouveaux inscrits, les bases sur mysql 4 des "anciens" n'étant pas migrées automatiquement.
PS: si vous avez votre propre serveur dédié, ça m'interresse aussi, indiquez alors "hébergement perso" comme nom d'hebergeur :-)
Commentaires
Bonjour,
hébergement @ home sur une debian etch x86_64 :
mysql Ver 14.12 Distrib 5.0.51, for debian-linux-gnu (x86_64) using readline 5.2
Des serveurs virtuels où je suis root et où donc j'installe ce que je veux. (du php 5.2 mini et mysql 5)
Sinon un mutualisé chez plexiweb : php 5.2.5 / mysql 5
2 RPS d'Ovh et 1 kimsufi Gentoo sur chaque machine avec php 5.2 et MySQL 5
Si tu as le temps de farfouiller, les forums de dotclear ont une discussion à propos de ça.
hébergement perso (SPV Debian etch) :
Avec mon "ancien" compte chez OVH, j'avais évidemment mysql4. Mais il y a une interface permettant de créer une nouvelle base avec un mysql5 (compte basique, 15/mois)
Hébergement perso (Gentoo x86_64)
-PHP 5.2.6RC4-pl0-gentoo (cli) (built: Apr 6 2008 14:00:15)
hébergement free/php5.2/postgresql 8
Salut Laurent,
Hébergement chez produweb.fr
PHP Version 4.4.8 MySQL 5.0.45
Infomaniak
PHP 5.2.5 MySQL 5.0.45
MySQL 4.1.11 PostgreSQL 7.4.7
Chez MediaTemple (gs) Grid-Service.
hébergement perso PHP 5.2.5 / MySQL 5.1
Oups, j'ai oublié PHP : 4.4.8 & 5.2.5
Une question que je me pose est l'interopérabilité d'une application web si on utilises des choses avancées comme des triggers, procédures stockées dans la base de données. Je suppose qu'il y a des incompatibiltés entre MySQL - PostgreSQL, ce qui limite malheureusement ce genre de pratique.
@omic : au contraire, le fait d'utiliser des procédures stockées augmente la compatibilité de l'appli. Il est de toute façon clair que pour l'installation de l'application tu vas fournir deux scripts SQL différents pour créer la base et les procédures stockées. Mais dans l'appli, tu auras moins de requêtes à faire, donc plus de chances d'avoir moins de problèmes d'incompatibilité. Bref, finalement, coté PHP, cela simplifie énormément les choses, tout en te permettant de profiter au maximum des possibilités de chaque base de donnée.
Dreamhost PHP: 5.2.X MySQL: 5.0.16
voilà, c'est 100 XPF ;)
@omic: boarf, y a pas 15000 SGBDR, suffit de développer le tintouin pour chaque "marque".
busted pour la réponse à omic :P
Hébergement perso PHP: 5.2.5 MySQL: 5.0.45
Mysql 5.0.51 et PHP 5.2.5 (prochainement Postgresql) / hébergement perso (dédié chez Sivit).
J'ai aussi un compte mutualisé chez Sivit, il propose maintenant Mysql 5 et PHP5 mais avec une bidouille .htaccess
Ubuntu server :
MySQL -> 5.0.45 PHP -> 5.2hébergement perso (dedibox) debian stable (paquets officiels)
Chez ovh, il te permette de créer une nouvelle base sql, même si tu n'en as qu'une de prévu dans ton contrat. Par contre si tu supprimes ta base mysql4 tu ne pourras plus en créer de nouvelle... Grâce à ce système n'importe qui chez Ovh, peut avoir une base mysql5. A savoir que la gestion innodb sur les bases mysql5 est encore moyennement géré par eux, dés qu'il y a une grosse base sur le serveur il commence à y avoir des complications...
Sur la 10aine de serveurs que nous gérons (~100aine de sites), c'est PHP 4.4.8 et PHP 5.2.x avec MySQL 4.0 ou 4.1 (MySQL 5.0 encore rare mais ça changera cette année).
Après pour ce genre d'infos, les stats nexen sont bien : http://www.nexen.net/chiffres_cles/phpversion/18282-evolution_de_php_sur_internet_mars_2008.php http://www.nexen.net/chiffres_cles/phpversion/18283-statistiques_de_deploiement_de_php_de_mars_2008.php
PHP est pas livré avec SQLite maintenant, qui a déjà ce genre de choses depuis bien longtemps ?
@loufoque : je ne vois nulle part où sqlite implémente les procédures stockées, mais par contre il est vrai qu'il implémente les triggers depuis sa version 2.5. Note aussi que dans PHP, il s'agit d'une version 2.x et non 3.x qui est embarquée (mais il existe une extension sqlite3 non officielle).
Si on veut des proc stock "depuis bien longtemps", mieux vaut se tourner vers posgresql ;-)
@SToto98 les stats de nexen ne montrent que php, pas mysql (ce qui m'interresse le plus)
PHP 5.2 et MySQL: 5.0
Il faudrait une initiative 'GoMySQL5' comme pour php (GoPHP5)
Hébergement perso sous Debian stable : mySQL : 5.0.41 (mise à jour programmé dans un ou deux mois) PHP : 5.2.0
createFunction et createAggregate c'est du vent ?
@loufoque: j'ai beau cherché sur le site sqlite.org, je ne trouve pas de telles fonctions. Même google ne trouve pas. Il y a une API en C, sqlite3_create_function mais ce n'est vraiment pas la même chose qu'une procédure stockée. Si tu pouvais m'indiquer l'url dans la documentation indiquant comment faire des procédures stockées en SQL dans sqlite (en d'autre terme, un CREATE PROCEDURE), je suis preneur...
Je parle des fonctions de l'API que fournit PHP... http://fr2.php.net/manual/en/function.sqlite-create-function.php http://fr2.php.net/manual/en/function.sqlite-create-aggregate.php
Sur les machines de mes clients j'installe systématiquement du Debian Stable Etch, c'est à dire PHP 5.2.0 et MySQL 5.0.32. - http://packages.debian.org/etch/mysql-server - http://packages.debian.org/etch/php5
Pour les clients ayant des besoins particuliers on utilise le repository "backborts.org", et donc il s'agit dans ce cas d'un MySQL 5.0.51.
Note en passant : via PDO il s'agit d'SQLITE v3.
@loufoque : ce ne sont pas des procédures stockées au sens SQL du terme. On ne peut donc faire de scripts 100% SQL, transposable d'une installation à une autre, indépendament du langage hote. Il y a de grosses différences avec les vraies procédures stockées SQL. Bref, on ne parle pas du tout de la même chose.
@loufoque : pour être plus précis, une procedure stockée SQL permet d'intégrer des rêgles de gestion à l'interieur même du schema de la base, permettant alors de garantir l'intégrité des données selon ces rêgles de gestion. Ce qui veut dire, que, quelques soit le client qui accéde aux données, ces rêgles de gestion seront implicitement appliquées et respectées, sans que le client ait à faire quoique ce soit de particulier.
Ce n'est pas le cas ici avec ces fonctions pour sqlite, car cela veut dire ici que c'est au client d'avoir les programmes permettant d'appliquer les rêgles de gestion. Cela revient donc au même que lorsqu'on développe un programme basé sur mysql 4 et précedent par exemple : il faut tout (re)faire au niveau du client. Dans le contexte d'une entreprise où il peut y avoir plusieurs clients de type différent (ex: un client MS Access, le site web de l'entreprise, l'appli intranet etc) qui attaquent la même base, le modèle proposé par sqlite n'est franchement pas utilisable. Mais c'est vrai aussi que sqlite n'est pas fait pour ce genre d'usage :-)
Cependant pouvoir faire de vraies procédures stockées faciliterait les imports/exports de schemas par ex..
Pense ce que tu veux, reste que c'est la même chose, en plus puissant même.
Apparemment c'est le fait que y'ait pas un serveur et un client qui te gêne...
@loufoque : c'est pas le fait qu'il n'y ait pas de serveur qui me gène. Y a pas de raison que ces procédures ne puissent pas être stockées avec le schema dans le modèle de sqlite.
Plus puissant ? Ça peut être interressant car c'est vrai qu'on a plus de possibilité qu'en SQL au niveau de la programmation, mais coté modélisation, c'est complètement incohérent comme je l'ai déjà dit, et coté performance, c'est tout aussi ridicule, en tout cas en PHP et autre langage web non compilé : devoir déclarer les fonctions à chaque page auprés de sqlite, sans compter les transtypages que doit faire l'API sqlite entre le moteur SQL et PHP, je me marre...