Reprise du message précédent :
18ko = 90% (pour relancer )

edit: grilled

tu as 20 ko et tu perd 18ko, donc tu perd 90%

Sauf si tu pars du fichier d'arrivé et que tu calcules le pourcentage pour arrivé au fichier original.
Encore aurait-il fallu le comprendre ou faire croire qu'on ne l'a pas compris.
C'est vrai quoi, 2 pages pour montrer comment calculer des pourcentages avec citations en anglais et tout.
L'élite a fait fort sur ce coup là.
 
 
C'est pathétique.........

on peut tourner la page ?

Ouais, alors le sujet, Clubic forum sucks.

le but c'est de rester en dessous des 100%.
c'est un peux comme si tu disais au lieu de -50%, tu disais 200% moins cher que le prix original ?!

C'est pas une question de vouloir jouer les intellectuels c'est une question de savoir faires des maths basiques et utiliser des pourcentages

Tu passes de 2ko à 20ko c'est une augmentation de 900%, tu passes de 20ko à 2ko c'est une réduction de 90% point barre, ça va pas plus loin, une réduction ou un gain de 900% c'est un passage dans le négatif que tu ça te plaise ou non.

Ce qui est aussi illogique qu'incorrect.

C'est illogique et surtout, ça ne présente aucun intérêt.

- 6 * 2 = 3 !
- non,  6 * 2 = 12 !
- mais si... si tu pars du résultat 3 * 2 = 6 , donc 6 * 2 = 3 !

Faut bien essayer de se rattraper aux branches
Je vois que le lancement du forum Clubic déchaîne les passions en tout cas

T'es juste un semeur de zizanie

Faut bien l'animer un peu ce topic

Bah, il y aura toujours quelqu'un à programmer un forum.

6*9=42

 
Ha non ! 6*9 = 36 !!!!
 
Gare à celui qui me contredira

N'importe quoi, 6*9 = FILE_NOT_FOUND c'est bien connu

6*9, c'est pas plustôt une erreur de position? L'étoile est en trop que diable.  
 
PS :  

 
 
Tient sinon, t'as matté le 1U là toi !  
 
http://forum.hardware.fr/hfr/Achat [...] 3622_1.htm
 

[HS]
On vient d'acheter un bi Xeon là
.. merci quand même  
[/HS]

 
Faudra que je passe voir ça

hmm, ça vaut le coup nan? j'ai un bout d'espace de rack a remplir... on met quoi comme ram dans cte bête la ?

 
Le 1U, à ce prix, il est donné en ram, ça mange de la SD PC133 ECC

Stop le HS Please

 
Pourtant il est en bon etat
 
 
---> []

Bonjour,
 
Désolé de vous recentrer dans le sujet .... J'ai créé le site skwat.com, qui n'est pas un forum, mais un réseau social. Je réfléchi à une manière d'indexer toutes les infos dont je dispose sur les vidéos, musiques, photos, membres... afin de créer une recherche rapide et optimisée tout en prévoyant une quantité d'informations importante à stocker.
 
Actuellement on fait une recherche fulltexte mais je sais bien que ce n'est pas viable, d'où ma question.
 
Que pensez vous de cette architecture :
 
Une table de mots
=> idMot
=> mot (clé unique)
=> nbRecherche
 
Avec des tables d'association, une pour chaque type d'info à stocker
 
Vidéos  / Musique  / Membre  / Photo
=> idVideo , idMusique, idMembre, idPhoto
=> idMot
 
Les infos seront ajoutées lors de l'édition des informations (photo, musique ...) ce qui me permet d'avoir en permanence mes tables à jour et de ne pas générer les réponses pour une recherche avec un cache ...
 
Lors d'une recherche limitée à un type de média (Vidéo par exemple), il me suffit de chercher le mot dans la table, et de faire une jointure en passant par la table d'association.
 
Je réfléchissais également à des recherches composées de plusieurs mots. Dans ce cas, Il faut pour chacun des mots faire la requête, et ordonner les informations en fonction des réponses qui correspondent au maximum de mots de la recherche.
 
Qu'en pensez vous ?
 
Comment avez vous fait pour vos forums ?
 
Merci,

Je pense que j'aurais plutot opté pour une seule table d'association du type :
type_media
id_media
idMot
 
id_media contient l'id de la vidéo, de la musique, du membre ou de la photo, selon le type.
type_media est un champ numérique (par exemple, 1 pour une vidéo, 2 pour une musique, etc...).
 
La dessus, tu rajoute un (un seul) index sur les colones (IdMot, type_media) pour améliorer les perfs de tes recherches :
- si un mec cherche un mot dans tous les médias, seul la première colone de l'index sera utilisé.
- si un mec cherche un mot dans un média particulier, les deux colones seront utilisés.
 
Par contre, après, si la recherche porte sur plusieurs mots, ou sur plusieurs types de média (mais pas tous), je ne sais pas comment se comportera MySQL pour les index. Il faut donc faire des tests, et utiliser les EXPLAIN.

Merci, je vais me pencher la dessus, je pense que c'est le plus performant... car les LIKE ... OR LIKE ... OR LIKE ...

C'est ce qu'il y a pour l'instant, afin d'avoir qqch de fonctionnel... mais l'objectif était justement d'y revenir afin d'avoir une solution viable.

 
T'aurais commencé comme ça directement, t'aurais eu qquechose de fonctionnel beaucoup plus rapidement

oui mais bon !

Surtout que tant qu'a utiliser le fulltext, autant utiliser les fonctions qui vont avec :
http://dev.mysql.com/doc/refman/5. [...] earch.html

Vous êtes d'accord qu'il vaut mieux faire une table spéciale pour la recherche, quitte à ce qu'elle soit énorme que du fulltext dans plusieurs tables ?

Plop tout le monde
 
Vous savez si on a le droit d'utiliser certaines icônes du forum hfr pour notre site ? (je pose la question ici à tout hasard avant de demander à Joce).
 
Merci

Perso, j'utilise ça, avec une petite mise en cache, de temps en temps, sur un quadriproc, ça tourne nickel  

Ca dépend lesquels

L'icône pour répondre en citant le message ainsi que celle pour envoyer un mp

De quel jeu d'icones

silk