bonjour
Je commence à regarder la programmation sous le trio apache, php et mysql et
ce que je viens de lire me donne des sueurs froides.
Je peux me tromper mais j'aimerais savoir ce que comptes faire la plus part
des hébergeurs (d'où ma question ici) lorsqu'ils mettront ou ferons l'update
de leurs php vers le fatitique php5 qui ne supporte plus de façon le support
mysql par défaut.
C'est à dire que si un hébergeur après l'udate veut supporter Mysql, il doit
le faire en paramêtrant le php.ini.
La question est donc la suivante.
Que comptez vous faire dans l'avenir???? Garder le trio ou faut il tout de
suite prévoir de passer sur un type de base. sqlite par exemple qui est le
support par défaut de la nouvelle monture de php???
Il veut dire que le ROOT server des .org utilise postgresql comme base de donnée.
Oui Afilias, opérateur technique du .ORG (et .INFO), utilise postgresql, depuis le début, et manifestement avec succès pour des dizaines voire centaine de milliers de transactions par jour. Ils contribuent même, et ont fourni une solution de réplication (Slony) qui manquait cruellement (en open source en tout cas) à PostgreSQL.
Le .ZA utilise aussi Postgresql, mais je n'en suis pas sûr.
Ma phrase était une boutade référencant une veille pub de Sun qui disait: ``Nous sommes le . de .COM''
(le .COM doit utiliser Oracle, je pense, comme le .FR)
Je pense que PostgreSQL n'a plus rien à prouver comme SGBDR, et que donc ce n'est plus du paraitre :-)
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
Il paraitrait même que c'est le . de .ORG ....
j'ai pas saisi la ...
Il veut dire que le ROOT server des .org utilise postgresql comme base
de donnée.
Oui Afilias, opérateur technique du .ORG (et .INFO), utilise postgresql,
depuis le début, et manifestement avec succès pour des dizaines voire
centaine de milliers de transactions par jour.
Ils contribuent même, et ont fourni une solution de réplication (Slony)
qui manquait cruellement (en open source en tout cas) à PostgreSQL.
Le .ZA utilise aussi Postgresql, mais je n'en suis pas sûr.
Ma phrase était une boutade référencant une veille pub de Sun qui disait:
``Nous sommes le . de .COM''
(le .COM doit utiliser Oracle, je pense, comme le .FR)
Je pense que PostgreSQL n'a plus rien à prouver comme SGBDR, et que donc
ce n'est plus du paraitre :-)
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Il veut dire que le ROOT server des .org utilise postgresql comme base de donnée.
Oui Afilias, opérateur technique du .ORG (et .INFO), utilise postgresql, depuis le début, et manifestement avec succès pour des dizaines voire centaine de milliers de transactions par jour. Ils contribuent même, et ont fourni une solution de réplication (Slony) qui manquait cruellement (en open source en tout cas) à PostgreSQL.
Le .ZA utilise aussi Postgresql, mais je n'en suis pas sûr.
Ma phrase était une boutade référencant une veille pub de Sun qui disait: ``Nous sommes le . de .COM''
(le .COM doit utiliser Oracle, je pense, comme le .FR)
Je pense que PostgreSQL n'a plus rien à prouver comme SGBDR, et que donc ce n'est plus du paraitre :-)
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
Wilk
"William" <Désolé@1.com> writes:
bonjour Je commence à regarder la programmation sous le trio apache, php et mysql et ce que je viens de lire me donne des sueurs froides.
Je peux me tromper mais j'aimerais savoir ce que comptes faire la plus part des hébergeurs (d'où ma question ici) lorsqu'ils mettront ou ferons l'update de leurs php vers le fatitique php5 qui ne supporte plus de façon le support mysql par défaut.
C'est à dire que si un hébergeur après l'udate veut supporter Mysql, il doit le faire en paramêtrant le php.ini.
La question est donc la suivante. Que comptez vous faire dans l'avenir???? Garder le trio ou faut il tout de suite prévoir de passer sur un type de base. sqlite par exemple qui est le support par défaut de la nouvelle monture de php???
<troll> Les hébergeurs vont laisser tomber le trio et le remplacer par python+twistedmatrix+posgresql </troll>
-- Wilk - http://flibuste.net
"William" <Désolé@1.com> writes:
bonjour
Je commence à regarder la programmation sous le trio apache, php et mysql et
ce que je viens de lire me donne des sueurs froides.
Je peux me tromper mais j'aimerais savoir ce que comptes faire la plus part
des hébergeurs (d'où ma question ici) lorsqu'ils mettront ou ferons l'update
de leurs php vers le fatitique php5 qui ne supporte plus de façon le support
mysql par défaut.
C'est à dire que si un hébergeur après l'udate veut supporter Mysql, il doit
le faire en paramêtrant le php.ini.
La question est donc la suivante.
Que comptez vous faire dans l'avenir???? Garder le trio ou faut il tout de
suite prévoir de passer sur un type de base. sqlite par exemple qui est le
support par défaut de la nouvelle monture de php???
<troll>
Les hébergeurs vont laisser tomber le trio et le remplacer par
python+twistedmatrix+posgresql
</troll>
bonjour Je commence à regarder la programmation sous le trio apache, php et mysql et ce que je viens de lire me donne des sueurs froides.
Je peux me tromper mais j'aimerais savoir ce que comptes faire la plus part des hébergeurs (d'où ma question ici) lorsqu'ils mettront ou ferons l'update de leurs php vers le fatitique php5 qui ne supporte plus de façon le support mysql par défaut.
C'est à dire que si un hébergeur après l'udate veut supporter Mysql, il doit le faire en paramêtrant le php.ini.
La question est donc la suivante. Que comptez vous faire dans l'avenir???? Garder le trio ou faut il tout de suite prévoir de passer sur un type de base. sqlite par exemple qui est le support par défaut de la nouvelle monture de php???
<troll> Les hébergeurs vont laisser tomber le trio et le remplacer par python+twistedmatrix+posgresql </troll>
-- Wilk - http://flibuste.net
Patrick Mevzek
Attention ne pas confondre SQLite, qui ne constitue qu'un système de bases de données simplifié intégré à PHP5 avec MySQL qui reste est restera supporté à l'avenir. Le SGBD SQLite n'est guère utilisable en production pour un site qui génère un minimum d'activité en base de données...
Ah bon ?
MySQL reste le système le plus sérieux accouplé à PHP, même en version 5.0.
Ah bon ? Le plus sérieux ? Sur quels critères ?
De plus, PHP5 reste compatible avec la majorité des scripts PHP4, et MySQL ne fait que s'améliorer.
Faut dire, ils partent de loin :-)
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
Attention ne pas confondre SQLite, qui ne constitue qu'un système de
bases de données simplifié intégré à PHP5 avec MySQL qui reste est
restera supporté à l'avenir. Le SGBD SQLite n'est guère utilisable en
production pour un site qui génère un minimum d'activité en base de
données...
Ah bon ?
MySQL reste le système le plus sérieux accouplé à PHP, même en version
5.0.
Ah bon ? Le plus sérieux ? Sur quels critères ?
De plus, PHP5 reste compatible avec la majorité des scripts PHP4, et
MySQL ne fait que s'améliorer.
Faut dire, ils partent de loin :-)
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Attention ne pas confondre SQLite, qui ne constitue qu'un système de bases de données simplifié intégré à PHP5 avec MySQL qui reste est restera supporté à l'avenir. Le SGBD SQLite n'est guère utilisable en production pour un site qui génère un minimum d'activité en base de données...
Ah bon ?
MySQL reste le système le plus sérieux accouplé à PHP, même en version 5.0.
Ah bon ? Le plus sérieux ? Sur quels critères ?
De plus, PHP5 reste compatible avec la majorité des scripts PHP4, et MySQL ne fait que s'améliorer.
Faut dire, ils partent de loin :-)
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
William
Re "Adrien" a écrit dans le message de news:
Bonjour William,
MySQL reste le système le plus sérieux accouplé à PHP, même en version 5.0.
Je n'ai pas controler car je ne l'ai pas installé la php5 mais d'après ma lecture il est bien dit que le support par defaut de mysql est désactivé
Moi sinon je ne demande pas mieux que de rester sur Mysql, c eux qui ne veulent pas :-(
cdl William
De plus, PHP5 reste compatible avec la majorité des scripts PHP4, et MySQL ne fait que s'améliorer.
Pas de panique ! :-)
Re
"Adrien" <adrien03@aol.com> a écrit dans le message de
news:1c385457.0408190245.46adb0b4@posting.google.com...
Bonjour William,
MySQL reste le système le plus sérieux accouplé à PHP, même en version
5.0.
Je n'ai pas controler car je ne l'ai pas installé la php5 mais d'après ma
lecture il est bien dit que le support par defaut de mysql est désactivé
Moi sinon je ne demande pas mieux que de rester sur Mysql, c eux qui ne
veulent pas :-(
cdl
William
De plus, PHP5 reste compatible avec la majorité des scripts PHP4, et
MySQL ne fait que s'améliorer.
MySQL reste le système le plus sérieux accouplé à PHP, même en version 5.0.
Je n'ai pas controler car je ne l'ai pas installé la php5 mais d'après ma lecture il est bien dit que le support par defaut de mysql est désactivé
Moi sinon je ne demande pas mieux que de rester sur Mysql, c eux qui ne veulent pas :-(
cdl William
De plus, PHP5 reste compatible avec la majorité des scripts PHP4, et MySQL ne fait que s'améliorer.
Pas de panique ! :-)
Rakotomandimby Mihamina
Patrick Mevzek wrote:
Il veut dire que le ROOT server des .org utilise postgresql comme base de donnée. Je pense que PostgreSQL n'a plus rien à prouver comme SGBDR, et que donc
ce n'est plus du paraitre :-)
Mais .... ca doit etre moi qui comprend mal mes documentations, mais il m'a toujours paru dans mes lectures que d'utiliser une SGDB pour les DNS etait plus long (en temps de transaction) que si on utilisait un ammuaire (genre OpenLDAP) ... ou bien c'est moi qui ai rien compris ?
Patrick Mevzek wrote:
Il veut dire que le ROOT server des .org utilise postgresql comme base
de donnée.
Je pense que PostgreSQL n'a plus rien à prouver comme SGBDR, et que donc
ce n'est plus du paraitre :-)
Mais .... ca doit etre moi qui comprend mal mes documentations, mais il
m'a toujours paru dans mes lectures que d'utiliser une SGDB pour les DNS
etait plus long (en temps de transaction) que si on utilisait un
ammuaire (genre OpenLDAP) ... ou bien c'est moi qui ai rien compris ?
Il veut dire que le ROOT server des .org utilise postgresql comme base de donnée. Je pense que PostgreSQL n'a plus rien à prouver comme SGBDR, et que donc
ce n'est plus du paraitre :-)
Mais .... ca doit etre moi qui comprend mal mes documentations, mais il m'a toujours paru dans mes lectures que d'utiliser une SGDB pour les DNS etait plus long (en temps de transaction) que si on utilisait un ammuaire (genre OpenLDAP) ... ou bien c'est moi qui ai rien compris ?
Rakotomandimby Mihamina
Wilk wrote:
"William" <Désolé@1.com> writes: <troll> Les hébergeurs vont laisser tomber le trio et le remplacer par python+twistedmatrix+posgresql </troll>
oh non : python + zope (avec sa base transactionnelle interne) + postgresql :-P
Wilk wrote:
"William" <Désolé@1.com> writes:
<troll>
Les hébergeurs vont laisser tomber le trio et le remplacer par
python+twistedmatrix+posgresql
</troll>
oh non : python + zope (avec sa base transactionnelle interne) +
postgresql :-P
"William" <Désolé@1.com> writes: <troll> Les hébergeurs vont laisser tomber le trio et le remplacer par python+twistedmatrix+posgresql </troll>
oh non : python + zope (avec sa base transactionnelle interne) + postgresql :-P
Patrick Mevzek
Patrick Mevzek wrote:
Il veut dire que le ROOT server des .org utilise postgresql comme base de donnée. Je pense que PostgreSQL n'a plus rien à prouver comme SGBDR, et que
donc ce n'est plus du paraitre :-)
Mais .... ca doit etre moi qui comprend mal mes documentations, mais il m'a toujours paru dans mes lectures que d'utiliser une SGDB pour les DNS etait plus long (en temps de transaction)
Ce n'est pas là qu'il est utilisé, ou pas principalement. Pour chaque domaine, il faut bien enregistrer qui en est le bureau d'enregistrement, les dates de création, renouvellement, transfert, les noms/adresses des propriétaires, contacts, etc.... Donc tout ca c'est dans un SGBDR. A partir duquel on fait effectivement le whois et la configuration des serveurs racines du TLD.
Vu les logiciels qu'ils ont réalisé, très probablement, ils ont une base maître, qui s'occupe des écritures, synchronisées avec une base (ou plus) pour le whois et une autre base (ou plus) pour les DNS, les deux dernières n'étant accédées qu'en écriture. Plus les copies de sauvegarde, etc...
(Quasimment) Tous les TLDs ont un SGBDR quelque part dans l'infrastructure.
etait plus long (en temps de transaction) que si on utilisait un ammuaire (genre OpenLDAP) ... ou bien c'est moi qui ai rien compris ?
Mouais, tout dépend de ce qu'on fait, du matériel, etc... Y a jamais un seul et unique vainqueur sur le papier dans tous les cas. LDAP n'est pas non plus réputé comme étant un flèche de course.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
Patrick Mevzek wrote:
Il veut dire que le ROOT server des .org utilise postgresql comme base
de donnée.
Je pense que PostgreSQL n'a plus rien à prouver comme SGBDR, et que
donc ce n'est plus du paraitre :-)
Mais .... ca doit etre moi qui comprend mal mes documentations, mais il
m'a toujours paru dans mes lectures que d'utiliser une SGDB pour les
DNS etait plus long (en temps de transaction)
Ce n'est pas là qu'il est utilisé, ou pas principalement.
Pour chaque domaine, il faut bien enregistrer qui en est le bureau
d'enregistrement, les dates de création, renouvellement, transfert, les
noms/adresses des propriétaires, contacts, etc....
Donc tout ca c'est dans un SGBDR.
A partir duquel on fait effectivement le whois et la configuration des
serveurs racines du TLD.
Vu les logiciels qu'ils ont réalisé, très probablement, ils ont une base
maître, qui s'occupe des écritures, synchronisées avec une base (ou plus)
pour le whois et une autre base (ou plus) pour les DNS, les deux
dernières n'étant accédées qu'en écriture.
Plus les copies de sauvegarde, etc...
(Quasimment) Tous les TLDs ont un SGBDR quelque part dans
l'infrastructure.
etait plus long (en temps de transaction) que si on utilisait un
ammuaire (genre OpenLDAP) ... ou bien c'est moi qui ai rien compris ?
Mouais, tout dépend de ce qu'on fait, du matériel, etc...
Y a jamais un seul et unique vainqueur sur le papier dans tous les cas.
LDAP n'est pas non plus réputé comme étant un flèche de course.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Il veut dire que le ROOT server des .org utilise postgresql comme base de donnée. Je pense que PostgreSQL n'a plus rien à prouver comme SGBDR, et que
donc ce n'est plus du paraitre :-)
Mais .... ca doit etre moi qui comprend mal mes documentations, mais il m'a toujours paru dans mes lectures que d'utiliser une SGDB pour les DNS etait plus long (en temps de transaction)
Ce n'est pas là qu'il est utilisé, ou pas principalement. Pour chaque domaine, il faut bien enregistrer qui en est le bureau d'enregistrement, les dates de création, renouvellement, transfert, les noms/adresses des propriétaires, contacts, etc.... Donc tout ca c'est dans un SGBDR. A partir duquel on fait effectivement le whois et la configuration des serveurs racines du TLD.
Vu les logiciels qu'ils ont réalisé, très probablement, ils ont une base maître, qui s'occupe des écritures, synchronisées avec une base (ou plus) pour le whois et une autre base (ou plus) pour les DNS, les deux dernières n'étant accédées qu'en écriture. Plus les copies de sauvegarde, etc...
(Quasimment) Tous les TLDs ont un SGBDR quelque part dans l'infrastructure.
etait plus long (en temps de transaction) que si on utilisait un ammuaire (genre OpenLDAP) ... ou bien c'est moi qui ai rien compris ?
Mouais, tout dépend de ce qu'on fait, du matériel, etc... Y a jamais un seul et unique vainqueur sur le papier dans tous les cas. LDAP n'est pas non plus réputé comme étant un flèche de course.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
Stephane Kanschine
On Thu, 19 Aug 2004 12:51:38 +0200, Patrick Mevzek wrote:
De plus, PHP5 reste compatible avec la majorité des scripts PHP4, et MySQL ne fait que s'améliorer.
Faut dire, ils partent de loin :-)
Trop gros, passera pas, c'était bien appaté pourtant :-)
-- Stephane Kanschine Amadouer l'anti-spam pour me répondre
On Thu, 19 Aug 2004 12:51:38 +0200, Patrick Mevzek wrote:
De plus, PHP5 reste compatible avec la majorité des scripts PHP4, et
MySQL ne fait que s'améliorer.
Faut dire, ils partent de loin :-)
Trop gros, passera pas, c'était bien appaté pourtant :-)
--
Stephane Kanschine
Amadouer l'anti-spam pour me répondre
On Thu, 19 Aug 2004 12:51:38 +0200, Patrick Mevzek wrote:
De plus, PHP5 reste compatible avec la majorité des scripts PHP4, et MySQL ne fait que s'améliorer.
Faut dire, ils partent de loin :-)
Trop gros, passera pas, c'était bien appaté pourtant :-)
-- Stephane Kanschine Amadouer l'anti-spam pour me répondre
Mikaël Poussard
Patrick Mevzek wrote:
Attention ne pas confondre SQLite, qui ne constitue qu'un système de bases de données simplifié intégré à PHP5 avec MySQL qui reste est restera supporté à l'avenir. Le SGBD SQLite n'est guère utilisable en production pour un site qui génère un minimum d'activité en base de données...
Ah bon ?
SQLite gère très mal les accès concurrentielles. Ce qui, tout de même, est un assez gros problème (surtout sur des sites non optimisés)...
MySQL reste le système le plus sérieux accouplé à PHP, même en version 5.0.
Ah bon ? Le plus sérieux ? Sur quels critères ?
C'est toujours une question de critères :)
De plus, PHP5 reste compatible avec la majorité des scripts PHP4, et MySQL ne fait que s'améliorer.
Faut dire, ils partent de loin :-)
Pas forcément, il y a de bonne choses dans MySQL comme la réplication, par exemple.
-- Mik
Patrick Mevzek wrote:
Attention ne pas confondre SQLite, qui ne constitue qu'un système de
bases de données simplifié intégré à PHP5 avec MySQL qui reste est
restera supporté à l'avenir. Le SGBD SQLite n'est guère utilisable en
production pour un site qui génère un minimum d'activité en base de
données...
Ah bon ?
SQLite gère très mal les accès concurrentielles. Ce qui, tout de même, est
un assez gros problème (surtout sur des sites non optimisés)...
MySQL reste le système le plus sérieux accouplé à PHP, même en version
5.0.
Ah bon ? Le plus sérieux ? Sur quels critères ?
C'est toujours une question de critères :)
De plus, PHP5 reste compatible avec la majorité des scripts PHP4, et
MySQL ne fait que s'améliorer.
Faut dire, ils partent de loin :-)
Pas forcément, il y a de bonne choses dans MySQL comme la réplication, par
exemple.
Attention ne pas confondre SQLite, qui ne constitue qu'un système de bases de données simplifié intégré à PHP5 avec MySQL qui reste est restera supporté à l'avenir. Le SGBD SQLite n'est guère utilisable en production pour un site qui génère un minimum d'activité en base de données...
Ah bon ?
SQLite gère très mal les accès concurrentielles. Ce qui, tout de même, est un assez gros problème (surtout sur des sites non optimisés)...
MySQL reste le système le plus sérieux accouplé à PHP, même en version 5.0.
Ah bon ? Le plus sérieux ? Sur quels critères ?
C'est toujours une question de critères :)
De plus, PHP5 reste compatible avec la majorité des scripts PHP4, et MySQL ne fait que s'améliorer.
Faut dire, ils partent de loin :-)
Pas forcément, il y a de bonne choses dans MySQL comme la réplication, par exemple.
-- Mik
Mikaël Poussard
Patrick Mevzek wrote:
etait plus long (en temps de transaction) que si on utilisait un ammuaire (genre OpenLDAP) ... ou bien c'est moi qui ai rien compris ?
Mouais, tout dépend de ce qu'on fait, du matériel, etc... Y a jamais un seul et unique vainqueur sur le papier dans tous les cas. LDAP n'est pas non plus réputé comme étant un flèche de course.
La principale différence entre les deux n'étant pas une question de rapidité mais d'organisation des données, LDAP étant hiérarchisé, SQL étant bordélisé.
-- Mik
Patrick Mevzek wrote:
etait plus long (en temps de transaction) que si on utilisait un
ammuaire (genre OpenLDAP) ... ou bien c'est moi qui ai rien compris ?
Mouais, tout dépend de ce qu'on fait, du matériel, etc...
Y a jamais un seul et unique vainqueur sur le papier dans tous les cas.
LDAP n'est pas non plus réputé comme étant un flèche de course.
La principale différence entre les deux n'étant pas une question de rapidité
mais d'organisation des données, LDAP étant hiérarchisé, SQL étant
bordélisé.
etait plus long (en temps de transaction) que si on utilisait un ammuaire (genre OpenLDAP) ... ou bien c'est moi qui ai rien compris ?
Mouais, tout dépend de ce qu'on fait, du matériel, etc... Y a jamais un seul et unique vainqueur sur le papier dans tous les cas. LDAP n'est pas non plus réputé comme étant un flèche de course.
La principale différence entre les deux n'étant pas une question de rapidité mais d'organisation des données, LDAP étant hiérarchisé, SQL étant bordélisé.
