Reprise du message précédent :
J'en ai déjà près d'une centaine.
 
Ca doit faire plus ou moins 25%?

je sais pas comment vous le faites mais moi j'avias penser a un tableau associatif
langue['bonjour']="hello";
ou un truc du genre

bon je lance un ptit débat avant d'aller pieuter à la demande de forummp3 qui trouvait la chose intéressante, je me quote donc sur le sujet qui a été évoqué vendredi soir sur blabla@prog:
 

 
La question sera donc: comment avez vous procédé pour analyser la problématique de la mise au point de votre forum? Je veux donc parler de ce que j'appelle plus haut "étude de l'existant" et "analyse fonctionnelle". Zavez préparé quelque chose ou vous avez foncé directement dans le développement?

ben moi mon permier forum tete baisser à la bourrin => pas fini trop de problemes.
2eme pareil en modifiant les pb du 1 => toujours des pb
et la le dernier ben j'avance petit à petit table par table en réfléchissant le plus avnat le codage mais bon c'est toujours un peu bourrin

seras t il possible un jour
Que ceux qui ont fait ca tout joliment (avec analyse préalable) publie leurs analyse ? histoire de voir ce que j'aurai du faire vraiment ?

MA v1 a l'arrache (débutant en MySQL)
v2, v3,v4 : nouveau modele de BDD, répond a des attentes de rapidités, et aussi avec mes connaissances en MySQL, j'ai pas eu de mal a réparer mes erreurs.

Pour etre bref, j'ai dessiné un schéma relationnel, et j'ai construit mes fonction en algo dessus
 
Puis j'ai tout adapté en PHP

merci drasche .... grace à toi j'ai pas pu dormir.
J'ai fait une légére petite étude pour voir ce que je pourrais mettre dans mon forum (de 4h à 7h du mat )
résultat ma version 0.8.2 => à la corbeille      
 
 
Donc d'un coté je te remercie j'ai beaucoup à jeter mais ca aurai pu etre pire
mais d'un autre je te deteste   ... j'ai pas dormis .

drasche c'est un footeur de mairde

 
L'étude de l'existant pour moi ça a été de voir 3 ou 4 forums qui existent déjà, me dire cette fonction c'est cool et chercher comment la faire Après c'était du bourin.    
 
Mais récement, j'ai quand meme fait l'effort de poser sur papier mes modèles de tables pour essayer d'optimiser un peu les nouvelles fonctionalités.

ouch, je ne pensais pas déclencher une telle remise en question
 

est-ce qu'on t'a demandé ton opinion à toi?
t'es déjà pas foutu d'aligner 2 lignes de code PHP
et j'aime pas le foot d'abord

et j'en suis fier, le PHP c'est pour les VBistes frustrés
 

moi ce que j'ai fait pour le forum tout d'abord c'est de faire la structure de la base de donné sur papier,ensuite ce que j'ai fait c'est au fur et a mesure je faisait l'algorythme de la page que j'allais faire comme cela j'avais l'algo tout frais dans ma tete.
L'algo c'est bien pratique car on a pas besoin de reflechir aux fonctions,aux erreurs,etc
 
Pour les exemple de forums,j'en ai pas pris beaucoup,seulement les forum que je connaissais,donc le forum ppc et phorum,car c'etait mon ancien forum.Vu que je voulais un forum simple et rapide,alors je n'ai pris que les fonctions de base.
Par contre je n'ai toujours pas programmé d'admin pour mon forum  

 
J'ai d'abord fait de l'espionnage industriel sur le forum ppc pendant quelques mois? (sans compter les tests discrets dans les PM's )

 
Oui, au départ je faisais des strings séparés genre  
 
$string_page_description_variable = "tutu";
 
mais ça ralentissait pas mal le forum.
 
Maintenant c'est  
 
$lang[page_description_variable] = "tutu";

En ce qui concerne les strings séparées, tu peux voir à en faire une accompagnant chaque page, sous forme d'un include qui créerait un tableau effectivement, comme ça chaque page n'est associée qu'à ses traductions.
 
Sur un projet sur lequel j'ai bossé, ils avaient fait un truc dans ce genre mais c'était un peu pourri parce que c'était une collection et toutes les traductions étaient dans l'include

Tiens, c koi le plus "standard" : $tablo['indice'] ou $table[indice] ? J'utilise toujours la première moi (sauf qd c numérique)

 
Ca fait déjà faire assez de gymnastique aux mains de foutre des crochets pour qu'on ne s'amuse pas à mettre des apostrophes en plus?

Si tu ne mets pas les guillemets, il parse ta valeur, ce qui fait qu'elle est considérée comme une variable. Donc c'est plus lent et plus risqué.

Bon ça va, je vais mettre des apostrophes?
 
Mes mains te remercient?    
 

bah oui, mais bon, sinon imagine qu'un petit malin arrive à faire un define sur le nom d'une variable que tu utilises...

Ca change beaucoup ?

Comment tu sais ca ? Je n'ai pas l'impression de l'avoir déjà vu dans la doc

http://www.php.net/manual/fr/language.types.array.php

Quand j'ai commencé mon analyse moi non plus    
 
Moi aussi j'ai une question:
il vaut mieux faire $ligne=mysql_fetch_row() ou $ligne=mysql_fetch_assoc()?
avec le premier on accède par : $line[1] par exemple.
Il parait (je sais plus ou j'ai lu ca) que c'est plus rapide.
Mais parcontre plus chiant si on doit déplacer des champs
avec le second c'est $ligne['tutu']
c'est plus lent (il parait) mais parcontre c'est cool plus besoin de se faire chier à tout décaler si on ne veus plus le premier de la requete.
 
Vous vous utilisez quoi ?

bha pour moi j'utilise ca :
list($champs1,$champs2)=mysql_fetch_row($result)
 
comme ca bha tu peux rajouter un champs dans le select dans pb et sa décale rien

 
mysql_fetch_array() quand y a pas mal de champs Mais des fois, je me met à utiliser mysql_fetch_row() si j'ai besoin que de 2 ou 3 champs (et presque plus jamais de SELECT *, je garde que quand j'ai besoin de tout les champs de la table).

les SELECT *, cai mal
ça oblige ton SGBD à aller chercher lui-même la liste des champs de ta table.

ca depend des cas,car en prenant que quelque colone,tu oblige ton sgbd a faire le trie,ce qui peut ralentir

  ca va toujour plus vite si on ne sélectionne que les champs dont on a besoin. J'avais fait le test et donné les temps de génération sur ce topic (vers la page 15, mais c'est pas sur), si t'as le courage de chercher

si tu avais des champ TEXT c'est normal qu'il y ai une difference,mais tu devrais essayer avec des champs de petite taille.

 
J'ai retrouvé : http://forum.hardware.fr/forum2.ph [...] 22#t464155
Il devait pas y avoir de champ text, que des varchar et des int.
 
J'essayerais. J'ai justement une toute petite table qui sera parfaitement adaptée à ça une fois chargée

Grrr, pas moyen de descendre ma page index en-dessous de 0.002 secondes de temps de génération?
 
Ca doit être parce que mon php+Apache n'aime pas tourner sous win32?

tiens dans le cadre de l'étude de forums, enfin, ça fait longtemps que j'ai vu ça mais je m'en suis rappelé, c'était un forum anglophone sur lequel les modos avaient une participation très active: les messages étaient validés par eux avant d'apparaître dans la liste des messages

Oui, ca existe encore sur de nombreux forums, notamment sur les sites de firmes déjà existantes comme les journaux ou des chaines de TV. Pour des entreprises de cette taille, cela peut se comprendre, mais pour les autres, c'est plus chiant qu'autre chose.

 
Tu as essayé avec un accélérateur quelconque?

 
C'était pour plaisanter, je trouve ça déjà pas mal 2 millisecondes?
 
Sinon ma tête a failli exploser pendant que je réécrivais le système d'authentification?  

Vais quand même essayer Zend Accelerator histoire de voir tiens?

Petite question de noob :
 
Dans une bdd, je veux stocker les date d'anniv des membres par exemple, en sachant que je vais aller les visionner qu'une fois tous les 6 mois.
 
Si je stocke les dates dans la table membre utilisé tous les jours, ca ralenti le système ou mysql est suffisamment optimisé pour ca ?

si tu fait select truc,much et que tu met pas la date c'est bon
c'est l'anniversaire de quelqu'un recement qui t'as fait penser a cette option?  

 
Donc ca "surcharge" pas la base.
 
l'anniv CT juste un exemple, parsque dans mon cas je veux logger l'IP utilisé lors de l'inscription du membre, le truc qui sers vraiment a rien, alors ca serait con de ralentir la base juste a cause de ca