Ainsi, la version 1.7 inclut :
- Apache 1.3.27
- PHP 4.3.3
- MySQL 4.0.15
- PhpMyAdmin 2.5.3
NdM : le software libre, c'est mieux sur une plateforme libre !
Bref, que du bon!
![[fr]](../images/fr.png)
Site officiel (1120 hits)-
Téléchargement (1042 hits)
-
L'annonce sur Kaoos (un peu d'auto-promo, ca fait pas de mal ;) (366 hits)
> Lire la dépêche (63 commentaires, moyenne: 1,5).
Vous avez demandé le commentaire #282835.
Run by 
Cette page a été générée par Templeet en 0.1132s (dont 0.0057 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Re: Sortie d'EasyPHP 1.7
Juste une question en passant: quels sont les avantages de MySQL par rapport à Postgres?
Ne me parlez pas de performances, personne ou presque n'a besoin de maxi-perfs... par contre, je suis convaincu que les vues et le procédures stockées sont de grands avantages pour rendre le code des applications plus clair (et bien souvent plus rapide), qu'il soit en PHP ou n'importe quoi d'autre. Donc, à part la raison "parce que je connais que ça", pourquoi MySQL plutôt que Postgres?
[^]Re: Sortie d'EasyPHP 1.7
http://www.google.fr/linux?hl=fr&ie=ISO-8859-1&q=postgresql(...)
Jabber ID : xmpp:Nyco@jabber.fr
[^]Re: Sortie d'EasyPHP 1.7
bin ici, vu le nombre de select par secondes on a pas le choix ...
postgre, oracle et sybase n'ont pas tenue ...
faut dire que vu le volume que cela représente ...
donc pour doodoo c'est mysql
[^]Re: Sortie d'EasyPHP 1.7
Le nombre de select important ne serait pas justement du à un manque d'utilisation des vues? De nombreux logiciels font des tas de requêtes qui peuvent en fait s'optimiser en passant les sous-requêtes en interne sur la base de données.
[^]Re: Sortie d'EasyPHP 1.7
non non ... c'est à cause du nombre important d'utilisateurs ...
10 millions de BAL, pour un webmail ça fait beaucoup ;-)
[^]Re: Sortie d'EasyPHP 1.7
Je me demandais, niveau vitesse, ou se situe mysql (embedded mysql en fait), par rapport à microsoft access? qq a déjà joué avec ça?
[^]Re: Sortie d'EasyPHP 1.7
EasyPHP etant probablement orienté vers les personnes désirant monter un site "amateur", les hébergement correspondant à ce genre de site comportent le plus souvent MySQL. C'est peut-être la raison principale d'avoir MySQL plutôt que Postgres.
[^]Re: Sortie d'EasyPHP 1.7
Pourquoi ? Mysql c'est un truc d'amateur ?
Vous ne pouvez pas imaginer l'expression pleine de candeur et d'innoncence de mon visage quand je dis ca.
[^]Re: Sortie d'EasyPHP 1.7
Mysql c'est un truc d'amateur ?
Disons plutôt que c'est une base de données assez basique (rien de négatif là dedans, y'a besoin de logiciels simples). Il n'empèche que ça marche très bien, mais ça n'offre pas beaucoup d'outils pouvant simplifier la vie du développeur ou permettant d'optimiser les requêtes au niveau du serveur au lieu de pousser les logiciels à faire des tonnes de requêtes.
[^]Re: Sortie d'EasyPHP 1.7
Peut-être pas, mais il est bon de savoir que mettre PHP et MySQL sur son CV, ça fait amateur.
Hé oui. Cruelle réalité, mais la totalité des recruteurs que j'ai croisé voient cela ainsi. Comme ce sont des technos relativement accessibles et très répandues, ce ne sont, dans leurs esprits, que des truds d'amateurs ; rien qui puisse valoir quelquechose, donc.
Par contre, pouvoir justifier en plus d'expérience sur d'autres bases et langages, tout de suite, ça change tout. Heureusement... :-)
[^]Re: Sortie d'EasyPHP 1.7
Ca n'est pas ce que j'ai voulu dire, bien que ma réponse serait "Oui" sans hésiter.
Non, je parlais de l'usage de EasyPHP : on ne peut décement pas monter un server web avec Windows/EasyPHP, ce qui en fait plutôt un environnement de développement pas cher (quand on a Windows) et facile d'installation.
Pour ce qui est de MySQL, bien que cette base fonctionne très bien, elle a de réelles lacunes pour un gros développement :
- Pas de sous-requêtes, ce qui induit une multiplication de requetes simples et un traitement par programme.
- Pas de contraintes d'intégrités référentielles, ce qui implique un contrôle strict côté programme qui ne garanti aucunement la cohérence des données.
- Pas de vues (même simples), d'où répétition et multiplication de requêtes.
- Pas de code stocké. Si ce point est discutable lorsqu'il s'agit de stocker beaucoup de code, ça l'est moins lorsqu'il s'agit de triggers simples permettant d'automatiser et de fiabiliser certains traitements.
[^]Re: Sortie d'EasyPHP 1.7
- Pas de sous-requêtes, ce qui induit une multiplication de requetes simples et un traitement par programme.
Corrigés dans la 4.1
- Pas de contraintes d'intégrités référentielles, ce qui implique un contrôle strict côté programme qui ne garanti aucunement la cohérence des données.
C'est vrai mais c'est quelque chose qu'il vaut mieux souvent gérés dans la logique métier de l'application... ca les exceptions postgreSQL qui remontent à l'utilisateur en erreur windows, c'est pas très beau
- Pas de vues (même simples), d'où répétition et multiplication de requêtes.
C'est vrai.
- Pas de code stocké. Si ce point est discutable lorsqu'il s'agit de stocker beaucoup de code, ça l'est moins lorsqu'il s'agit de triggers simples permettant d'automatiser et de fiabiliser certains traitements.
Comme je l'ai déja dit, le code stocké dans la base de données est une mauvaise idée mais ce n'est que mon avis :)
[^]Re: Sortie d'EasyPHP 1.7
Corrigés dans la 4.1
Excellente nouvelle, je vais de ce pas me replonger dans la documentation (il y a sous-requête et sous-requête).
C'est vrai mais c'est quelque chose qu'il vaut mieux souvent gérés dans la logique métier de l'application... ca les exceptions postgreSQL qui remontent à l'utilisateur en erreur windows, c'est pas très beau
Effectivement, deux possibilités :
- Doubler le contrôle en l'effectuant aussi dans la couche applicative (mais ça n'est pas très intéressant d'effectuer un traitement en double),
- Gérer les exceptions correctement (je ne connais pas PostgreSQL mais Oracle) : c'est idéal.
Le gros avantage des contraintes référentielles est de garantir la cohérence des données, ce que la couche applicative, malgré toute l'attention apportée au code, ne peut garantir lorsque le proget est concéquent.
[^]Re: Sortie d'EasyPHP 1.7
Je préfère dans ce cas la, gérer tout dans la logique applicative et écrire plus de tests unitaires.
[^]Re: Sortie d'EasyPHP 1.7
C'est leur côté rassurant (et le manque de rigueur de nos développeurs) qui me fait pencher vers l'utilisation les contraintes.
Je viens d'aller faire un tour dans la doc MySQL, c'est très intéressant... la conclusion est : Vivement la 5.1 !
En effet, les procédures stoquées devraient être disponibles à partir de la 5.0 et les clés étrangères à partir de la 5.1.
[^]Re: Sortie d'EasyPHP 1.7
C'est sur qu'on peut creer une classe MonTrigger pour eviter de mettre du code dans la BD. On peut aussi recréer un systeme de stockage en utilisant des fichiers Properties. Mais franchement, ca alourdi pas un peu le code ? Et pire, ca ne serait pas un peu moins performant ? Les (bonnes) bases de données fournissent les contraintes d'intégrité, les trigger, le tout standardisé, c'est pas pour qu'on reinvente la roue tout les jours.
Bon, Ok, en meme temps on est libre, hein, on fait ce qu'on veut.
[^]Re: Sortie d'EasyPHP 1.7
Ecrire du code qui vérifie qu'on supprime pas un client qui a encore des factures n'est pas plus long à écrire en code qu'en procédures stockées.
Ce que je veux juste dire, c'est que je préfère que ce soit coder dans l'application et avoir un traitement clean que je puisse vérifier avec des tests unitaires que d'avoir une erreur qui remonte de la bd et qui arrive sur l'écran du client :)
[^]Re: Sortie d'EasyPHP 1.7
Pas plus long a écrire...Je sais pas j'ai un doute. Il te faut instancier un Statement, executer la requete et compter le nombre de ligne du ResultSet (ouais c'est en tres gros et tres moche, mais tu vois l'idée). Avec une contrainte d'integrité, tu ne pourra tout simplement PAS effacer un client qui aura des factures (a cause de la foreign key), et tu auras une belle exception. A mon avis (je ne suis pas un pro, ni meme un developpeur :) ) c'est plus long a taper (au moins trois lignes en plus), et ca surcharge plus la db (une connection en plus pour la requete déjà). Ok, je pinaille mais tant qu'on y est...le reseaux aussi (bah oui ton Resultset il passe par le reseaux).
Enfin je dit ca je dit rien, moi je ne suis ni developpeur ni DBA de metier :)
[^]Re: Sortie d'EasyPHP 1.7
eheh ok car les choses ont bien changées...
Désormais, c'est plutot
public void supprimerClient(String idClient) throws Exception {
Client client = ClientUtil.getHome().findByPrimaryKey(idClient);
if ( client.getFactures().count() == 0 ) {
client.remove();
} else {
throw new Exception("Le client possède encore des factures");
}
}
Voila, dessus ça, on fait aussitot un test unitaire correspondant et c'est emballé :)
Je reste indépendant de ma bd et ma logique métier est concentrée à un seul endroit.
[^]Re: Sortie d'EasyPHP 1.7
Je précise que ce traitement a lieu sur le serveur d'applications, ce qui ne génère donc aucune charge réseau ( si le serveur d'applications et la bdd sont sur la même machine)
[^]Re: Sortie d'EasyPHP 1.7
Ok, là c'est transparent pour toi, mais ton serveur J2EE il instancie un PrepareStatement de plus dans l'histoire que si tu tentait directement un "Delete client where...". Tu bouffes de la memoire, du temps d'execution, des lignes de code (bah oui, tu tapes 5 lignes ou un "try catch" suffit), de la ressource niveau base de donnée (une requete en plus). Donc bon, plus rapide, je ne suis toujours pas convaincu.
Tu es independant de ta bd ? Pour recentrer le debat et etre plus exact, ca te permet de migrer de Postgres a Mysql sans encombre, parceque Mysql ne gere pas les contraintes d'intégrités. Si tu bossait avec des "vrai" (je ne veut pas etre pejoratif, mais je ne sais pas comment dire autrement) BD, c'est a dire gerant tout ca, un simple "dump" suivi d'un "restore" du schema te permettrait de conserver cette intégrité referencielle qui nous tient tant a coeur a moi et a mon troll...
A puis tient un autre : En plus tu fait ca en J2EE, c'est super lent de faire des findByPrimaryKey par rapport a un select tout bete. Mais bon, c'est pas ta faute, les EJB c'est lent on n'y peut rien. J'espere que t'utilise JEREMIES au moins.
[^]Re: Sortie d'EasyPHP 1.7
C'est faux, déja il y a un cache pour les statements et pour les resultsets dans la plupart des serveurs J2EE.
je ne crois pas qu'on puisse le faire en moins de ligne que ce que je viens de faire... ca m'étonnerait...
J'ai déja migré de oracle vers mysql et vice versa, je vois pas le prb dont tu parles.
regarde le code source de JOnAS par exemple, un finbyBYPrimaryKey se traduit par un select.. donc ecplique moi la différence ?
tu n'as pas du beaucoup t'en servir des ejbs :)
et dernièrement , j'aimerai qu'on discute de manière cool :)
tu as l'air d'être un peu sur les dents.. reste calme ! :D
[^]Re: Sortie d'EasyPHP 1.7
Ah mais je suis pas du tout enervé, detend toi.
La migration de oracle vers Mysql ne pose pas de probleme si le schema sous oracle n'utilise pas de contraintes d'intégrité (ou alors que l'appli ne les utilise pas). Dans le cas contraire tu aurais du reprendre le code pour en tenir compte, chose que tu n'aurais pas eu a faire pour un portage vers postgres par exemple (totalement au hasard l'exemple), qui si je ne m'abuse respecte la norme en matiere de declaration de foreign keys.
La difference entre un findbyPrimaryKey et un select, c'est justement le temps de passage de l'un a l'autre (ok je pinaille enormement là), mais bon le fond de la question n'etait pas la et c'etait juste pour embeter les pro-EJB, j'avoue.
A part ca:
Statement st =new Statement("delete client....where..."); try{st.executeQuery();}catch( SQLException ex) {System.out.println("Something Wicked happened...); }
Voila,en une ligne moi Monsieur :)
[^]Re: Sortie d'EasyPHP 1.7
Alors la, eheh tu triches un peu, moi aussi, je peux faire court :
Client client = ClientUtil.getHome().findByPrimaryKey(idClient); if ( client.getFactures().count() == 0 ) client.remove(); else throw new Exception("Le client possède encore des factures");
si on compte les instructions (;) on en est au même nombre :)
sauf que tu caches ta mise en place de la variable idClient ;) et que je n'utilise aucun code SQL ;)
enfin je persiste, meme si tu as des foerign keyrs dans ton dump sql de ta base, tu les joues dans MySQL et tout se passe nickel. MySQL ne tiendra pas compte des fk bien sur mais ton application tournera aussi bien.
[^]Re: Sortie d'EasyPHP 1.7
Ok, en J2EE ca marche bien, java c'est trop fort, on est d'accord (meme si tu triche aussi quand tu dit que tu n'utilises pas de code SQL, il est juste planqué dans ton findbyPrimaryKey)...
Tiens d'ailleurs, il me semble qu'on peut faire des "foreign key" entre EJB, non ? comment ca se passe quand tu fait ton client.remove() ? il peut faire du "delete cascade" ?
[^]Re: Sortie d'EasyPHP 1.7
eheh je triche pas, c juste pas moi qui l'écrit :)
Moins j'en fais, mieux je me porte :D
oui, avec XDoclet, tu as juste un paramètre à mettre à true ( cascade-delete)
Style :
/**
* @ejb.interface-method
* @ejb.relation
* name="categorieTarifaire-clients"
* role-name="client-appartientA-categorieTarifaire"
* target-ejb="CategorieTarifaire"
* cascade-delete="yes"
*/
public abstract CategorieTarifaireLocal getCategorieTarifaire();
voila
[^]Re: Sortie d'EasyPHP 1.7
si on compte les instructions (;) on en est au même nombre
Tu ne veux pas compter le nombre de () tant qu'on y est? Au niveau performances, ce que tu proposes est une abomination, et c'est dû à un manque dans la base de données. Tu peux toujours dire ce que tu veux.
J'ajouterais aussi que si tu veux que ce code gère de façon valide la cohérence des données, il faut qu'il soit exécuté en section critique de façon à interdire les insertions dans la base entre la requête de vérification et la requête de suppression (sans parler des caches à proscrire). Donc non seulement ton code n'est pas efficace, mais en plus il n'est pas valide.
Autrement, le jour où une base de données plus rapide que MySQL mais ne supportant pas les clefs primaires verra le jour, combien de développeurs viendront nous dire "oui, mais c'est à l'application de gérer ce genre de contrainte, on peut faire des requêtes pour vérifier avant les insertions"?
Je préfère largement que ce soit un outil qui vérifie la cohérence des informations plutôt que de devoir passer derrière le code de chaque développeur pour vérifier s'il ne casse pas l'une des contraintes que le projet impose... je suis un développeur faignant, comme tout bon développeur (aïeuu, mes chevilles)
[^]Re: Sortie d'EasyPHP 1.7
Ce que tu viens de dire est un peu bête... carrément même.
pour comparer le nombre de lignes, on compare le nombre d'instructions sinon tu mets tout sur la même ligne... bref.
Mon code est efficace et valide, " faut qu'il soit exécuté en section critique " ne veut ABSOLUMENT rien dire.
De plus, si tu fais des bases de données sans clés primaires, ca ne m'étonnerait pas.
voila... ta réponse état vraiment ridicule mais merci quand même
[^]Re: Sortie d'EasyPHP 1.7
dirais tu que Google est un site d'amateur ??????
yahoo aussi ?
MySQL est une base de données extraordinaire, facile d'utilisation, peu de maintenance...
de plus SAPDB va se rapprocher de MySQL ce qui lui permettra d'avancer encore plus vite !
[^]Re: Sortie d'EasyPHP 1.7
MySQL est beaucoup plus facile d'administration que postgreSQL.
les procédures stockées sont à mon avis une ERREUR, elle te lit à une base de données.
Je connais pas mal d'applications qui utilisent des procédures stockées avec SQL server et qui ne peuvent donc pas migrer vers aytres choses. Meme si postgreSQL fait du ANSI92, ca n'assure pas de pouvoir migrer facilement d'une base vers une autre.
Quand aux vues... ouais.. bof :=)
Perso, quand je développe une application, j'aime bien pouvoir migrer d'une base à une autre en moins d'une demi journée :)
J'aime pas avoir les pieds et main liées.
[^]Re: Sortie d'EasyPHP 1.7
Perso, quand je développe une application, j'aime bien pouvoir migrer d'une base à une autre en moins d'une demi journée :)
J'aime pas avoir les pieds et main liées.
Moi aussi j'aime bien, c'est pour ca que ca me saoule de me recoder l'equivalent des 'on delete cascade' quand je passe une appli de oracle/postgres a Mysql.
[^]Re: Sortie d'EasyPHP 1.7
bon, je suis peut etre un cas particulier mais c'est vrai qu'avec les technologies que j'utilise, la base de données ne sert juste qu'à faire un stockage de masse ( dans 99% des cas ).
Je n'ai donc pas à faire les cascade delete et autres trucs de ce genre
[^]Re: Sortie d'EasyPHP 1.7
Dans ce cas là, pourquoi utiliser une base de données relationnelle ?
Je suis sûr qu'il existe des outils puissants pour du stockage de masse, et bien plus simples à utiliser que MySQL... Probablement plus rapides et plus légers...
Non ?
(NB: comme vous le verrez plus bas, je suis pro-Zope, mais dans ce post je ne parle aucunement de cette solution... plutôt un truc simple et léger...)
[^]Re: Sortie d'EasyPHP 1.7
Personnellement, j'utilise J2EE donc je me moque du moyen de stockage... ca représente pour moi 4 lignes dans un fichier de configuration...
Je crée mes objets et c'est le serveur d'application qui gère la persistance en sauvegardant les objets là ou je lui indique.
Ca pourrait être en JDO, des fichiers XML, des bases de données...
SInon, MySQL me parait être le plus simple et le plus répandu ( meilleur support )
Et à la question "pourquoi utiliser une base de données relationnelle ?" ... beh je crois que c'est ce qu'on a fait de plus solide et de plus rapide pour stocker des données ?
de plus, les bases de données relationnelles sont un peu passées dans le moeurs non ?
[^]Re: Sortie d'EasyPHP 1.7
beh je crois que c'est ce qu'on a fait de plus solide et de plus rapide pour stocker des données ? de plus, les bases de données relationnelles sont un peu passées dans le moeurs non ?
Bah, ce n'est pas parce que c'est relationnel qu'on a ces propriétés de rapidité et de solidité... Je suis sur qu'il existe des solutions pour faire ça sans utiliser de SGBDR...
Mais, comme tu dis, c'est passé dans les moeurs... Et puis pour un hébergeur, c'est plus simple de ne proposer que MySQL, plutot que plusieurs solutions...
[^]Re: Sortie d'EasyPHP 1.7
je dis juste que ce sont des caractéristiques des SGBDR :)
La rapidité, le support et la solidité des fichiers textes, XML ou des sgbd objets sont quand même pas reconnus non ?
Qu'utilises tu toi ?
[^]Re: Sortie d'EasyPHP 1.7
Je n'ai pas d'appli qui ait besoin de super-grosse performance à titre personnel.
Pour ce qui est du web, j'utilise Zope... donc la ZODB pour le stockage (ou une base SQL pour des requetes "avancées"... relationnelles...
Pour toute autre chose, j'utilise du fichier texte ^_^
C'est pour ça que je n'affirme rien ici... Je suppose juste :)
[^]Re: Sortie d'EasyPHP 1.7
dbm ?
hum j'ai du trop trainer dans le monde Perl.
Mais personnellement je ne vois pas l'interet d'utiliser un SGBDR si ce n'est pour gerer toutes les problematiques liées aux relations entre données.
Autre point qui n'est pas abordé dans le thread: je n'ai pas encore vu une application un peut large dont le stockage de données ne soit pas accédé par plusieurs programmes, écrits à plusieurs epoques par plusieurs developpeurs (ne serai-ce que les outils de maintenance, généralement baclés en cours ou fin de projet).
Si ma base force des contraintes d'intégrités, ca fait raler tout le monde (surtout pour les effacements ), mais je suis quasi certain de pas avoir de données orphelines.
Si ma base ne le permet pas, il faut que tous les développeurs s'assurent dans leur bout d'application de ne pas oublier toutes les contraintes de toutes les tables qu'ils manipulent.
Mais bien sur comme toute le monde le sait: les projets et les structures de données sont toujours bien documentés, les developpeurs tous excellents, les délais largement confortables et de toute façon comme tout le monde va faire des choses bien propres et que les couches logiques (applicative, metier ...) ne sont jamais violées, ca n'est pas un probleme.
My 10E-9cents
[^]Re: Sortie d'EasyPHP 1.7
On Delete Cascade sous MySQL :
http://www.mysql.com/doc/en/InnoDB_foreign_key_constraints.html(...)
[^]Re: Sortie d'EasyPHP 1.7
D'un autre côté, tu ne changes pas non plus trop souvent de SGBD. Et les vues, ça peut être très intéressant, même si bien sûr on peut s'en passer.
En fait, je vois un peu MySQL comme l'équivalent du RISC pour les processeurs: c'est plutôt simple (voire «basique» même si ce n'est pas vraiment le terme), mais ça trace. PostgreSQL offre des fonctions bien plus avancées (un peu l'équivalent du CISC), mais est plus lent. Tout est une question d'utilisation de ces fonctions avancées. Si tu ne les utilises pas réellement, tu prends MySQL, sinon PostgreSQL (par exemple).
[^]Re: Sortie d'EasyPHP 1.7
Tu ne changes pas souvent car on a l'habidtude de se "marrier" avec un SGBD
mais quand on arrive aux limites d'un SGBD, ou que les couts de maintenance deviennent trop élevé ou qu'un nouveau produit dix fois mieux vient de sortir.. je trouve ça agréable de pouvoir changer pour un faible coût :)
Pour faire une analogie, opn ne migre pas souvent de Windows à Linux...
Mais si cela devenait facile ? hein ? il n'y aurait pas d'interets ?
Je pense qu'il ne sert à rien de se bloquer :)