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???
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é. ^^^^^^^^^
relationnel, vous vouliez dire sans doute :-) ?
Il est clair qu'un SGBDR est moins adapté pour stocker des structures hierarchique que quelque chose de déjà hierarchisé. C'est pas impossible, mais pas pratique, on est d'accord.
Si on revient au sujet initial, au niveau d'un registre, y a pas vraiment de hierarchie, c'est ``à plat'', donc un SGBDR s'y prête bien.
Et si on veut pinailler, LDAP et SQL ne sont que des formats d'interrogation. Ils sont, sur la papier, indépendant de la façon dont les données sont stockées (c'est opaque dans le cas d'un SGBDR, et on peut choisir différentes méthodes dans le cas d'openLDAP, d'ailleurs j'ai fait pour un projet spécifique un back end shell qui traduisait des requêtes LDAP en requêtes SQL).
Il est vrai qu'il y avait un projet, dans les labos de Verisign, pour faire un whois basé sur LDAP. Ce n'est a posteriori pas l'approche retenue au final par le groupe IETF ad hoc.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
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é.
^^^^^^^^^
relationnel, vous vouliez dire sans doute :-) ?
Il est clair qu'un SGBDR est moins adapté pour stocker des structures
hierarchique que quelque chose de déjà hierarchisé. C'est pas impossible,
mais pas pratique, on est d'accord.
Si on revient au sujet initial, au niveau d'un registre, y a pas vraiment
de hierarchie, c'est ``à plat'', donc un SGBDR s'y prête bien.
Et si on veut pinailler, LDAP et SQL ne sont que des formats
d'interrogation. Ils sont, sur la papier, indépendant de la façon dont
les données sont stockées (c'est opaque dans le cas d'un SGBDR, et on
peut choisir différentes méthodes dans le cas d'openLDAP, d'ailleurs j'ai
fait pour un projet spécifique un back end shell qui traduisait des
requêtes LDAP en requêtes SQL).
Il est vrai qu'il y avait un projet, dans les labos de Verisign, pour
faire un whois basé sur LDAP. Ce n'est a posteriori pas l'approche retenue au
final par le groupe IETF ad hoc.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
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é. ^^^^^^^^^
relationnel, vous vouliez dire sans doute :-) ?
Il est clair qu'un SGBDR est moins adapté pour stocker des structures hierarchique que quelque chose de déjà hierarchisé. C'est pas impossible, mais pas pratique, on est d'accord.
Si on revient au sujet initial, au niveau d'un registre, y a pas vraiment de hierarchie, c'est ``à plat'', donc un SGBDR s'y prête bien.
Et si on veut pinailler, LDAP et SQL ne sont que des formats d'interrogation. Ils sont, sur la papier, indépendant de la façon dont les données sont stockées (c'est opaque dans le cas d'un SGBDR, et on peut choisir différentes méthodes dans le cas d'openLDAP, d'ailleurs j'ai fait pour un projet spécifique un back end shell qui traduisait des requêtes LDAP en requêtes SQL).
Il est vrai qu'il y avait un projet, dans les labos de Verisign, pour faire un whois basé sur LDAP. Ce n'est a posteriori pas l'approche retenue au final par le groupe IETF ad hoc.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
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 ?
SQLite gère très mal les accès concurrentielles.
Vous avez quelque chose de concret à ce sujet ? Une URL par exemple ?
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 :)
C'est pour cela que je demande sur lesquels...
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.
Sans transactions, c'est loin d'être un exploit IMNSHO...
Et j'espère que ca s'est amélioré parce que la réplication MySQL telle que je l'avais vue il y 2 ou 3 ans, c'était bof bof (un exemple: je construis une table temporaire sur le maitre, et hop ca fout en l'air la réplication dès que je sors de la session, en détruisant la table).
-- 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 ?
SQLite gère très mal les accès concurrentielles.
Vous avez quelque chose de concret à ce sujet ? Une URL par exemple ?
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 :)
C'est pour cela que je demande sur lesquels...
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.
Sans transactions, c'est loin d'être un exploit IMNSHO...
Et j'espère que ca s'est amélioré parce que la réplication MySQL telle
que je l'avais vue il y 2 ou 3 ans, c'était bof bof (un exemple: je
construis une table temporaire sur le maitre, et hop ca fout en l'air la
réplication dès que je sors de la session, en détruisant la table).
--
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 ?
SQLite gère très mal les accès concurrentielles.
Vous avez quelque chose de concret à ce sujet ? Une URL par exemple ?
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 :)
C'est pour cela que je demande sur lesquels...
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.
Sans transactions, c'est loin d'être un exploit IMNSHO...
Et j'espère que ca s'est amélioré parce que la réplication MySQL telle que je l'avais vue il y 2 ou 3 ans, c'était bof bof (un exemple: je construis une table temporaire sur le maitre, et hop ca fout en l'air la réplication dès que je sors de la session, en détruisant la table).
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
Mikaël Poussard
Patrick Mevzek wrote:
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é. ^^^^^^^^^
relationnel, vous vouliez dire sans doute :-) ?
Voila, c'est le mot que je cherchais :-)
Si on revient au sujet initial, au niveau d'un registre, y a pas vraiment de hierarchie, c'est ``à plat'', donc un SGBDR s'y prête bien.
Voila.
-- Mik
Patrick Mevzek wrote:
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é.
^^^^^^^^^
relationnel, vous vouliez dire sans doute :-) ?
Voila, c'est le mot que je cherchais :-)
Si on revient au sujet initial, au niveau d'un registre, y a pas vraiment
de hierarchie, c'est ``à plat'', donc un SGBDR s'y prête bien.
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é. ^^^^^^^^^
relationnel, vous vouliez dire sans doute :-) ?
Voila, c'est le mot que je cherchais :-)
Si on revient au sujet initial, au niveau d'un registre, y a pas vraiment de hierarchie, c'est ``à plat'', donc un SGBDR s'y prête bien.
Voila.
-- Mik
Ronnie Garcia
Rakotomandimby Mihamina wrote:
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
<troll> non, J2EE + Jonas + Postgresql =) </troll>
-- Ronnie Garcia <ronnie at mk2 dot net>
Rakotomandimby Mihamina wrote:
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
<troll>
non, J2EE + Jonas + Postgresql =)
</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
<troll> non, J2EE + Jonas + Postgresql =) </troll>
-- Ronnie Garcia <ronnie at mk2 dot net>
Wilk
Ronnie Garcia writes:
Rakotomandimby Mihamina wrote:
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
<troll> non, J2EE + Jonas + Postgresql =)
Et c'est ainsi que les hébergeurs mutualisés firent tous faillite et les hébergeurs dédiés fortune !
</troll>
Je sors du troll avec une vraie question : pour les mutualisés, est-ce php5 va apporter quelque chose aux hébergeurs ou l'inverse ? (plus gourmand ? plus de facilités de restrictions ?)
-- Wilk - http://flibuste.net
Ronnie Garcia <ronnie@INVERSE.net.mk2> writes:
Rakotomandimby Mihamina wrote:
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
<troll>
non, J2EE + Jonas + Postgresql =)
Et c'est ainsi que les hébergeurs mutualisés firent tous faillite et
les hébergeurs dédiés fortune !
</troll>
Je sors du troll avec une vraie question : pour les mutualisés, est-ce
php5 va apporter quelque chose aux hébergeurs ou l'inverse ? (plus gourmand
? plus de facilités de restrictions ?)
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
<troll> non, J2EE + Jonas + Postgresql =)
Et c'est ainsi que les hébergeurs mutualisés firent tous faillite et les hébergeurs dédiés fortune !
</troll>
Je sors du troll avec une vraie question : pour les mutualisés, est-ce php5 va apporter quelque chose aux hébergeurs ou l'inverse ? (plus gourmand ? plus de facilités de restrictions ?)
-- Wilk - http://flibuste.net
William
Merci à tout le monde même si on c un peu écarté :-) Cdl William
-- joindreWilliam at hotmail.com en instantanée
Merci à tout le monde même si on c un peu écarté :-)
Cdl
William
Merci à tout le monde même si on c un peu écarté :-) Cdl William
-- joindreWilliam at hotmail.com en instantanée
Lascap
William wrote:
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.
Rien à voir avec le php.ini. Le tout est de compiler php 5 avec le bon argument ainsi que, il est vrai, d'avoir sur le système les headers de mysql. Donc, pas de soucis, je ne pense pas que les hébergeurs abandonneront mysql, même pour sqlite, en tout cas pas tout de suite.
Pascal
William wrote:
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.
Rien à voir avec le php.ini. Le tout est de compiler php 5 avec le bon
argument ainsi que, il est vrai, d'avoir sur le système les headers de
mysql.
Donc, pas de soucis, je ne pense pas que les hébergeurs abandonneront
mysql, même pour sqlite, en tout cas pas tout de suite.
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.
Rien à voir avec le php.ini. Le tout est de compiler php 5 avec le bon argument ainsi que, il est vrai, d'avoir sur le système les headers de mysql. Donc, pas de soucis, je ne pense pas que les hébergeurs abandonneront mysql, même pour sqlite, en tout cas pas tout de suite.
Pascal
Lionel
Ronnie Garcia wrote:
<troll> Les hébergeurs vont laisser tomber le trio et le remplacer par python+twistedmatrix+posgresql </troll>
<troll> non, J2EE + Jonas + Postgresql =)
malheureusement trop beau pour être vrai....
</troll>
Ronnie Garcia wrote:
<troll>
Les hébergeurs vont laisser tomber le trio et le remplacer par
python+twistedmatrix+posgresql
</troll>
