Fonctions, triggers et procedures dans phpM yAdmin

On 02/04/2011 22:11, Pascal Poncet wrote:

Bonsoir à tous,

Bonjour,

Une question bête concernant l'interface d'administration phpMyAdmin :
Y a-t-il un moyen, lorsqu'on a sélectionné une base, d'avoir à cet
endroit une liste des fonctions utilisateur, triggers et autres
procédures qui ont été créées pour cette base ?

Cela n'existe pas à l'origine et cela demande une modification des
templates ainsi que des scripts associés, mais c'est faisable.
Par contre, si tu fais cela "dans ton coin", tu auras des souci pour
maintenir ton phpMyAdmin.

Je pense à une éventuelle configuration comme celle qui permet de
visualiser les références entre les tables, soit
$cfg['Servers'][$i]['pmadb'] et le script associé.
Hélas, je n'ai rien trouvé dans le manuel à ce sujet.

Ca ne sera pas faisable avec une simple modification de la configuration.
Il va falloir ajouter un onglet dans db_structure.php, pour par exemple
pointer sur db_functions.php (page à créer), qui permette de lancer les
requêtes "SHOW TRIGGERS", "SHOW CREATE FUNCTION" et "SHOW CREATE
PROCEDURE", et mettre en forme les résultats.

A mon avis, le plus simple (mais peut-être aussi le plus long) serait
peut-être de demander sur le tracker
(http://sourceforge.net/tracker/?group_id#067&atid77411), voire
t'investir dans le groupe de développement.

P.S.: Bien que ce sujet soit plutôt orienté MySQL, il est très
intéressant ici car phpMyAdmin me semble un incontournable pour la
plupart des développeurs PHP.

--
Tchattez en liberté: http://www.zeolia.net
Aide informatique: http://www.g33k-zone.org

Le 03/04/2011 15:39, CrazyCat a écrit :

Cela n'existe pas à l'origine et cela demande une modification des
templates ainsi que des scripts associés, mais c'est faisable.

C'est bien ce que je craignais.
D'ailleurs, c'est assez surprenant que cette fonctionnalité n'ait pas
été intégrée, depuis le temps que l'interface existe, et vu le nombre de
versions.

Je me demande si ce n'est pas une preuve indirecte que les développeurs
PHP/MySQL utilisent peu, ou pas, les routines SQL 2003 !
Serait-ce dû au succès de l'hébergement mutualisé ?

Par contre, si tu fais cela "dans ton coin", tu auras des souci pour
maintenir ton phpMyAdmin.

Exact, et en plus c'est un peu une trahison du principe open source.

A mon avis, le plus simple (mais peut-être aussi le plus long) serait
peut-être de demander sur le tracker
(http://sourceforge.net/tracker/?group_id#067&atid77411), voire
t'investir dans le groupe de développement.

Ou les deux, si j'ai du temps et que personne d'autre n'a de solution.
Sinon, je me rabattrais sur les outils gratuits disponibles chez
MySQL/Oracle (Workbench, par exemple).

En tous cas merci beaucoup pour les infos.

--
Cordialement,
Pascal

On 03/04/11 14:39, CrazyCat wrote:

P.S.: Bien que ce sujet soit plutôt orienté MySQL, il est très
intéressant ici car phpMyAdmin me semble un incontournable pour la
plupart des développeurs PHP.

Heureusement que tu as mis « la plupart ». :o)
Cet outil introduit souvent des bogues, car la plupart de ces
utilisateurs sont des débutants, qui ne comprennent pas ce qu'ils font.
Du coup, c'est (toujours ?) mal configuré. Et un utilisateur avancé sait
qu'il ira plus vite et aura plus de puissance en passant par un éditeur
de texte et l'invocation d'une commande (depuis l'éditeur, évidement).

Bref, je ne pense pas pour ma part que cette discution a sa place
ici. Ce serait plutôt pour fr.comp.infosystemes.www.auteurs.

J'ai dit que je n'aime pas PHPMyAdmin ? :)

Le 03/04/11 23:11, Pascal Poncet a écrit :

Je me demande si ce n'est pas une preuve indirecte que les développeurs
PHP/MySQL utilisent peu, ou pas, les routines SQL 2003 !
Serait-ce dû au succès de l'hébergement mutualisé ?

En même temps, les développeurs qui ont besoins de procédures stockées,
triggers et fonctions utilisent plutôt des bases de données sérieuses
comme PostgreSQL.

Je peux avoir loupé un épisode, mais l'avenir de MySQL n'est-il pas
incertain avec son rachat par Oracle ?

--
Bruno Baguette

On 06/04/11 15:23, Bruno Baguette wrote:

En même temps, les développeurs qui ont besoins de procédures stockées,
triggers et fonctions utilisent plutôt des bases de données sérieuses
comme PostgreSQL.

Je marche dedans. Les dévelopeurs qui utilisent les procédures
stockées dans MySQL le font souvent pour des raisons de performances
(histoire de court-circuiter l'analyse SQL), aucunement pour assurer la
logique métier du modèle et aler au-delà de la persistance.

Je peux avoir loupé un épisode, mais l'avenir de MySQL n'est-il pas
incertain avec son rachat par Oracle ?

MySQL n'a pas été racheté par Oracle. C'est Sun Microsystem qui avait
racheté MySQL AB qui a été racheté par Oracle.

Ceci dit, MySQL est un logiciel libre sous GPL qu'il est difficile de
tuer par le rachat de la société de service qui avait été créée pour
faire vivre des développeurs de MySQL.

Maintenant, il y a un fork mené par Michael Widenius, le fondateur de
MySQL AB, qui s'appelle Drizzle. À l'occasion, il a créé une nouvelle
société sur le modèle qui lui a déjà réussi par le passé.

Le 06/04/2011 16:23, Bruno Baguette a écrit :

En même temps, les développeurs qui ont besoins de procédures stockées,
triggers et fonctions utilisent plutôt des bases de données sérieuses
comme PostgreSQL.

Bon, on est un peu (voire totalement) hors charte mais, comme le
newsgroup est modéré, je suppose qu'on est implicitement autorisé à
développer le sujet.

Euh... MySQL, c'est pas un SGBDR sérieux ?
Faudra le dire à Google, Amazon, Fnac, etc.
Je veux bien en discuter, car rien n'est définitivement acquis, mais il
faudra quand même amener quelques arguments solides avant toute
conclusion hâtive.

Même dans le contexte particulier des routines, triggers et events, je
ne vois pas de faiblesse manifeste à leur implémentation de SQL 2003.

Je n'ai pas encore eu l'occasion de tester le parallélisme, la
réplication ou le clustering, mais je n'ai pas entendu dire que c'était
une daubasse.

Je peux avoir loupé un épisode, mais l'avenir de MySQL n'est-il pas
incertain avec son rachat par Oracle ?

Hélas, il semble bien incertain, du moins dans ses perspectives de
développement, car Oracle est réputé le positionner définitivement en
entrée de gamme, anti-cannibalisation oblige.

Maintenant, l'alternative semble très sérieuse du côté de MariaDB.
Voir [http://mariadb.org/].

De plus, pour revenir dans la charte, il n'y a apparemment aucun
problème à utiliser PHP en client.
Voir [http://kb.askmonty.org/v/mariadb-versus-mysql]


--
Cordialement,
Pascal

Le 07/04/11 00:01, Pascal Poncet a écrit :

Le 06/04/2011 16:23, Bruno Baguette a écrit :

En même temps, les développeurs qui ont besoins de procédures stockées,
triggers et fonctions utilisent plutôt des bases de données sérieuses
comme PostgreSQL.

Bon, on est un peu (voire totalement) hors charte mais, comme le
newsgroup est modéré, je suppose qu'on est implicitement autorisé à
développer le sujet.

On est complètement hors charte, je vais donc positionner la suite du
débat sur fr.comp.applications.sgbd, ca ne fera pas de tort (on y sera
en charte), et puis ca y roupille, pour le moment...

Euh... MySQL, c'est pas un SGBDR sérieux ?
Faudra le dire à Google, Amazon, Fnac, etc.
Je veux bien en discuter, car rien n'est définitivement acquis, mais il
faudra quand même amener quelques arguments solides avant toute
conclusion hâtive.

Même dans le contexte particulier des routines, triggers et events, je
ne vois pas de faiblesse manifeste à leur implémentation de SQL 2003.

Je n'ai pas encore eu l'occasion de tester le parallélisme, la
réplication ou le clustering, mais je n'ai pas entendu dire que c'était
une daubasse.

Bon, puisque j'ai ouvert la fosse à trolls, j'assume ! :-)

Je précise que j'ai été zieuter les récents changements de MySQL par
honnêteté, dès fois que... Et j'ai bien fait puisque changements il y a eu.

A l'époque (un bail) où j'ai fait mes choix, MySQL ne gérait pas les
sous-requêtes, ni les procédures stockées. PostgreSQL répondait à mes
besoins, je n'ai pas changé de SGBDR depuis.

Jusqu'il y a peu (fin 2010), MySQL était une daubasse dans sa
configuration par défaut, c'est à dire avec le moteur MyISAM (pas de
clef étrangères, acceptation de données plus grandes que la colonne
censée la recevoir, ...)

En d'autres termes, vous pouviez virer un enregistrement référencé par
d'autres (et donc perdre la cohérence de vos données), ou vous pouviez
insérer une chaine de 200 caractères dans un varchar(20) sans que MySQL
ne vous refuse l'insertion (et donc vous retrouver avec une chaine
tronquée).

Enfin, si vous utilisez une table (en insert ou en update) en MyISAM
lors d'un plantage du serveur, vous aviez de bonnes chances de vous
retrouver avec une table corrompue.

Bref, utiliser MySQL avec MyISAM relève de l'inconscience (surement une
grosse partie des utilisateurs), ou de la folie furieuse à moins de
savoir *ce que l'on fait*.

Le rachat de MySQL par Oracle aura permit (c'est peut-être la seule
bonne chose), que le moteur par défaut ne soit plus MyISAM, mais bien
InnoDB (qui appartenait déjà à Oracle avant, si je ne me trompe pas).

Un comparatif des fonctionnalités et des performances serait intéressant
à refaire (à moins qu'un comparatif *récent* ne soit déjà fait). Je ne
suis pas bien placé pour le faire puisque je n'utilise que rarement
MySQL (et aussi parce que je n'ai pas le temps de le faire, mais ca je
ne le dis pas !).

Pour l'aspect de la réplication, je ne vais pas m'aventurer sur ce
terrain, je n'ai jamais utilisé cela avec MySQL (uniquement en
PostgreSQL). Donc je n'ai pas d'expérience à donner sur ce point ! :-)

Je peux avoir loupé un épisode, mais l'avenir de MySQL n'est-il pas
incertain avec son rachat par Oracle ?

Hélas, il semble bien incertain, du moins dans ses perspectives de
développement, car Oracle est réputé le positionner définitivement en
entrée de gamme, anti-cannibalisation oblige.

Enfin, entre une DB MySQL/PostgreSQL,... ou une DB Oracle, il y a une
grosse marge de coût quand même (serveur, DBA,...).

Maintenant, l'alternative semble très sérieuse du côté de MariaDB.
Voir [http://mariadb.org/].
De plus, pour revenir dans la charte, il n'y a apparemment aucun
problème à utiliser PHP en client.
Voir [http://kb.askmonty.org/v/mariadb-versus-mysql]

J'en avais entendu parler, mais j'ignorait qu'ils étaient compatibles
avec le client MySQL (quand on voit l'auteur, on comprend mieux ensuite).

Le tout est de voir s'il sera adopté largement, mais c'est sans doute
trop tôt ? Il y a aussi Drizzle, un fork signalé par Mickael.

--
Bruno Baguette

Le 07/04/2011 08:37, Bruno Baguette a écrit :

Bon, puisque j'ai ouvert la fosse à trolls, j'assume ! :-)

Ah ouais, et un beau. M'étonne que tu nous sortes pas MongoDB !
On sait : MySQL, Apache et PHP, c'est nul. Un vrai (quoi ?), ça utilise
MongoDB, nginx et Python.

A l'époque (un bail) où j'ai fait mes choix, MySQL ne gérait pas les
sous-requêtes, ni les procédures stockées. PostgreSQL répondait à mes
besoins, je n'ai pas changé de SGBDR depuis.

Ouais, moi je suis sous Amiga depuis 1985 parce que les PC, c'était tout
pourri ! Depuis, je suis passé sur Amiga 3000 ! ;)

Jusqu'il y a peu (fin 2010), MySQL était une daubasse dans sa
configuration par défaut, c'est à dire avec le moteur MyISAM (pas de
clef étrangères, acceptation de données plus grandes que la colonne
censée la recevoir, ...)

En même temps, si t'es quiche au point de toujours utiliser des configs
par défaut et considérer que ce qui est par défaut défini la qualité du
produit...

MyISAM n'est-il pas bcp plus rapide qu'InnoDB ?
Si pour certaines bases je n'ai pas besoin de rollback, de foreign key
et autres spécificités, *pourquoi* devrais-je m'imposer InnoDB ? Parce
que ça fait plus sérieux ?

Mais, ok, le simple fait que ça appartienne désormais à Oracle me donne
*grandement* envie d'utiliser autre chose (et donc probablement
PostgreSQL). Tout comme j'essaie VMWare Player à la place de VirtualBox
(mais j'ai l'impression que c'est bien plus lent)
Et, bien sûr, je suis passé sur LibreOffice.
Tout ceci, je le reconnais, est encore plus arbitraire que ton choix :)

On 04/07/2011 08:37 AM, Bruno Baguette wrote:

Euh... MySQL, c'est pas un SGBDR sérieux ?
Faudra le dire à Google, Amazon, Fnac, etc.
Je veux bien en discuter, car rien n'est définitivement acquis, mais
il faudra quand même amener quelques arguments solides avant toute
conclusion hâtive.

En fait, Ça dépend énormement du besoin qui a amené au choix de MySQL.
Je doute fortement de fait qu'Amazon enregistre ses ventes dans des
tables MyISAM, par exemple. Ces grosses boites utilisent plusieurs
outils, d'Oracle à divers projets NoSQL

Même dans le contexte particulier des routines, triggers et events, je
ne vois pas de faiblesse manifeste à leur implémentation de SQL 2003.

Je n'ai pas encore eu l'occasion de tester le parallélisme, la
réplication ou le clustering, mais je n'ai pas entendu dire que
c'était une daubasse.

Là ou MySQL a un vrai probleme, c'est quand on commence a parler un peu
sérieusement d'exploitation. Comparant tous les jours avec PostgreSQL,
y'a pas photo. Je ne compte plus les réplications MySQL cassées, sans
qu'on sache comment c'est arrivé, et ou le fix tient de l'improbable.

Le rachat de MySQL par Oracle aura permit (c'est peut-être la seule
bonne chose), que le moteur par défaut ne soit plus MyISAM, mais bien
InnoDB (qui appartenait déjà à Oracle avant, si je ne me trompe pas).

Un comparatif des fonctionnalités et des performances serait intéressant
à refaire (à moins qu'un comparatif *récent* ne soit déjà fait). Je ne
suis pas bien placé pour le faire puisque je n'utilise que rarement
MySQL (et aussi parce que je n'ai pas le temps de le faire, mais ca je
ne le dis pas !).

Petits résumés :
- http://wiki.postgresql.org/wiki/Why_PostgreSQL_Instead_of_MySQL_2009
- http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL

Pour l'aspect de la réplication, je ne vais pas m'aventurer sur ce
terrain, je n'ai jamais utilisé cela avec MySQL (uniquement en
PostgreSQL). Donc je n'ai pas d'expérience à donner sur ce point ! :-)

Le gros avantage de PostgreSQL, c'est qu'on a le choix de l'outil, et ce
grâce à une chose toute simple : la communauté de développeurs autour de
PostgreSQL

Maintenant, l'alternative semble très sérieuse du côté de MariaDB.
Voir [http://mariadb.org/].
De plus, pour revenir dans la charte, il n'y a apparemment aucun
problème à utiliser PHP en client.
Voir [http://kb.askmonty.org/v/mariadb-versus-mysql]

J'en avais entendu parler, mais j'ignorait qu'ils étaient compatibles
avec le client MySQL (quand on voit l'auteur, on comprend mieux ensuite).

Le tout est de voir s'il sera adopté largement, mais c'est sans doute
trop tôt ? Il y a aussi Drizzle, un fork signalé par Mickael.

Il y a aussi SkySQL ; De mon point de vue, c'est le chaos, ça a commencé
quand Oracle a racheté InnoDB.


Bref, la sortie est là -> http://www.postgresql.org/

--
Sébastien

On 04/07/2011 01:42 PM, Olivier Masson wrote:

MyISAM n'est-il pas bcp plus rapide qu'InnoDB ?

Si, en effet.

Si pour certaines bases je n'ai pas besoin de rollback, de foreign key
et autres spécificités, *pourquoi* devrais-je m'imposer InnoDB ? Parce
que ça fait plus sérieux ?

Oui ! C'est plus "sérieux", dans le sens ou ça respecte ACID.

Vous pouvez utiliser MyISAM si vous êtes conscient que vous pouvez
perdre des données, sans être prévenu, et si ça n'est pas grave pour vous.

Ça ne répond pas au même besoin, c'est tout.

--
Sébastien