Reprise du message précédent :

ben je sais pas, je demandais justement

est ce qu'il existe un equivalent à phpmyadmin pour postgre car c'est vrai que postgre à l'air pas mal du tout !http://www.commandprompt.com/ppbook/index.lxp
 

phpPgAdmin

lorill a écrit a écrit :   phpPgAdmin

génial

mais sans vouloir être médisant, le fait qu'il existe phpMyAdmin et phpPgAdmin semble montrer que php n'a pas de couche d'abstraction correcte, sinon y'aurait besoin que d'un projet et une ou deux ligne de parametrage

Je ne sais pas si la  couche d'abstraction est correcte mais il est tres facile de changer de bdd avec php!
cf http://www.php.net/manual/fr/ref.pgsql.php et http://www.php.net/manual/fr/ref.mysql.php

ben pourquoi ils ont fait deux projets distincts alors ?
dans php3 y'avait des mysql_ceci, des mysql_cela un peu partout, si ca a pas evolué, c'est pas si facile que ca.
 
Edit: vu tes liens, c'est bien ce que je craignais...
supaire, on vient de changer de base, va falloir modifier partout ou on accède a la bdd, et va falloir changer, car avec postgres on peut aller a la ligne untel, avec mysql faut faire des fetch_row...

y'a encore des mysql ceci et des pg cela ...
Je crois que l'on sait mal compris parceque je connais pas encore bien postgre .
 C'est facile de changer de bdd mais ca prend du temps car toutes les requetes devront être modifiées !
 

 
C'est pas ce que j'appelle facile. En java par exemple, si on utilise pas les extensions non normalisées, il faut changer deux lignes pour tout le programme, un driver (une classe qui gère l'acces a la base de données, c'est elle la fameuse couche d'abstraction) et une url qui indique ou se connecter.

avec un peu de recul, t'as raison, les comandes php sont un peu différentes et il y en a pas beaucoup qui se ressemble (seulement les plus courantes !!! mais c'est celles que je vais utiliser (connect,fetch_array...))  

ohan a écrit a écrit : avec un peu de recul, t'as raison, les comandes php sont un peu différentes et il y en a pas beaucoup qui se ressemble (seulement les plus courantes !!!)

cela dit je suis persuadé qu'il existe une ou des couches d'abstractions pour php, si t'es pas certain de garder la même base tout le temps, je te conseille de chercher un peu de ce coté la.

c'est pour cela que j'ai lancé le topic, pour avoir une idée de la base à choisir et trouver la bonne du premier coup !

 
ben a la limite suffit de la faire hein, spa trop compliqué en restant basique

facile de changer de base en php :
 
les fonctions pg et mysql prennent quasiment les meme argument et renvoient les memes résultat, il suffit de ce creer une bibliotheque de fonctions genre base_connect($host,$login,$pass) et apres de mettre le code qui correspond a ta base derriere.
 
Tu fais 2 fichiers différents, un pour mysql et un pour pg, et apres tu inclus le bon.

ouais, mais les requetes qui n'ont pas forcément la même gueule (au pif, un create table qui prend des types equivalents, mais pas identiques)

c'est un peu comme ca que je voulais faire mais il n'y a pas le même nombre de fonction pour mysql et postgre dans php (61 contre 48) mais je crois que les fonctions de bases y sont pour les 2.

la couche d'abstraction sous php dont vous parliez  : pear

ba le forum y a pas besoin de tous ces trucs (bon ok, les subqueries pourraient s'averer parfois utile, mais on peut très bien faire sans, rien qu'en utilisant des jointures adéquates). preparedStatements, ca arrive aussi avec MySQL-4.1, le gars qui s'occupe du dev MySQL chez PHP fait déjà mumuse avec, et obtient un gain de 15 à 20%

joce a écrit a écrit : ba le forum y a pas besoin de tous ces trucs (bon ok, les subqueries pourraient s'averer parfois utile, mais on peut très bien faire sans, rien qu'en utilisant des jointures adéquates). preparedStatements, ca arrive aussi avec MySQL-4.1, le gars qui s'occupe du dev MySQL chez PHP fait déjà mumuse avec, et obtient un gain de 15 à 20%

 
ben ca va pouvoir ressembler a qqchose alors

 
ben ca aussi c possible de le faire, en rajoutant une couche d'abstraction ... on se fait chier, mais c possible

HappyHarry a écrit a écrit :     ben ca va pouvoir ressembler a qqchose alors

clair
pour l'instant c'est moi qui fait mumuse avec les subqueries sous MySQL-4.1 (voir le nombre de bugs reporté par moi sur les subqueries et autre derived table )

Sauf que c'est plus difficile d'intégrer des optimisations spécifiques à chaque base

C'est clair : la flexibilté se fait toujours au détriment des performances