• [^] # Re: contre

    Posté par . En réponse au journal Petition MYSQL chez Nerim. Évalué à 2.

    > tu auras plus vite fait de changer de proc ...

    Si tu veux aller sur ce terrain là, tu as encore plus vite faite de licencier un mec comme toi et externaliser ta prod en roumanie. tu veux un lien, ? nous avons eu un contact aujourd'hui , une boite qui nous a appelé (et nous sommes dans un bled paumé.)

    sur www[dot]filingrom[.]com il y a des gens qui t'expliquent que des gens comme toi/moi, on n'en a plus besoin, c'est encore mieux que de prendre un proc plus gros (ca coute pas chère) ou même un disque encore plus gros pour éviter d'avoir à nettoyer tes fichiers temporaires.

    Pour revenir sur la question des mysql_connect, il y a des gens qui travaillent avec plusieurs bases de données différentes et qui ont donc des connections DIFFERENTES et donc, qui ne veulent/peuvent pas réutiliser par défault la dernière connection automatique. Ensuite c'est php et pas mysql qui le fait en automatique. Ensuite je te propose de faire un test interessant :

    fait une connection host1 - base1 -> print id : Ressourceid#4 (par ex)
    ensuite encore host1 - base1 -> print id : Ressourceid#4 (normal, suivant ta théorie car php réutilise la dernière connection)
    MAIS host1 - base 2 -> print id : Ressourceid#4 (je ne comprend pas !!!, ce n'est pas le même connexion, et tu n'a pas assez aux mêmes tables.)
    Est-ce à dire que toutes les certitudes ne sont pas certaines.

    Donc avant je faisait, en gros un connect() à chaque accès, maintenant je 'trie' les connections pour n'ouvrir que des connexions nécessaires. Dans tes scripts tu ne donnes pas un identifiant de connexion ? tu laisses php prendre par défault le dernièr utilisé ? arggg

    >C'est une stat qui ne veut rien dire. Ca a du être fait en faisant 10000 fois 1+1
    >dans une boucle et en comparant avec autant d'appels de fonction qui font
    >chacune 1+1.
    >Dans un cas réel on est très loin de ces chiffres, et non, si tu fais une fonction
    >qui appelle une fonctiton qui appelle une fonction, ton code n'est pas
    >magiquement 1OOx plus lent, heureusement.

    Je ne sais pas, comment cela ce fait-il que en c, les compilos (si j'ai tout compris) peuvent inliner (recopier les fonctions à l'intérieur du code pour 'optimiser' en grossissant le binaire ?) si c'était un truc que même des boites comme yahoo ne pouvait économiquement pas utiliser, pourquoi les compilos se prennent le choux avec ?)

    Oui, oui allons dans les " blabla $var bliobli..." oui c'est cool, même avec un
    "select * from base where id= $_POST['login'] "cela va plus vite à coder et plus vite à analyser et... un peu goret qd même.

    Tu considères que des "" à la place des '' c'est des bidouilles ?

    Réutiliser du code existant ? cela voudrait dire le passer en revue pour qu'il devienne 'trusted' pour moi et mon employeur (autant de temps que de le réécrire), si je suis employé et que je fournis du code 'emprunté' à d'autres, demain, mon travail sera 'donné' à d'autre.
    Mon expertise du métier est de fournir du code 'sur mesure' pour des applis 'sur mesure' celui qui veut un outils de blogs dotclear, il le télécharge tout seul comme un grand. il y a tellement d'applis/script php écrit avec les pieds ou dans un soucis pédagogique que je ne mettrais pas en prod.
    Je ne 'certifie' pas un code que je n'écris pas (pour gagner du temps). Lorsque je mets un code en ligne, je sais qu'il marche pour ce quoi il a été concus et demain, je peux modifier FACILEMENT et sans contrainte ses fonctionnements car je le CONNAIS parfaitement.

    Alors Non, ce ne sont pas des applis à 200 euros, mais bien plus, si tu veux travailler pour pas chèr avec de la réintégration du travail d'autres, c'est un choix/obligation du marché. A ce niveau là, les pays de l'est vont ceuillir ce marché très facilement.
    Nous proposons du sur mesure, intégré à un processus de travail de l'entreprise, quelque chose que les autres ne peuvent pas faire, car il ne peuvent pas se déplacer dans l'entreprise qui va l'utiliser et faire les 3 liens supplémentaires (inutiles) dont Mme roger aura besoin pour "comprendre" les 3 opérations : elle ne comprends pas que achat/vente/règlement est une MEME opération de flux financier.

    Je me souviens de l'article que j'avais écrit en 2001 sur sam mag : de mémoire, "la réponse de la communauté php à un article critque de ZDNET") j'expliquais que php était fort car on travaillait avec des applis taillées à la serpe sur mesure et pas avec des blocs logiciels tout prèts. Il ne serait plus vrai aujourd'hui.

    Le choix politique de l'object en php5 pour attirer les dev java ne fait pas l'unanimité au sein du canal historique php, pourquoi d'après toi ?

    Je ne rentre même pas dans la réthorique de la course à la puissance, pourquoi me faire chier à optimiser, y des proc bi-core qui arrivent.