jcaron

Si tu génères du HTML (par opposition à un bitmap), en CSS tu peux indiquer une taille en cm ou en mm... Si tu génères un bitmap, dans la plupart des formats tu peux préciser la résolution théorique de ton fichier. Ceci dit, si tu veux vraiment être sûr du résultat, je te conseille de générer du PDF plutôt que du HTML ou un bitmap. Jacques.

Perso, je ne vois pas bien en quoi la découpe en plusieurs tables ferait gagner quoi que ce soit: le volume final de données étant le même, à condition de les bons index soient en place, ça ne changera rien, le premier niveau de l'index (qui fait grosso-modo l'équivalent de la découpe) va être en cache en permanence... Le partitionnement c'est utile dans de nombreux cas, mais ce n'est pas une recette miracle non plus, il faut qu'il y ait une bonne raison pour que ça apporte quoi que ce soit (et dans de nombreux cas ça va au contraire réduire les perfs, sans parler de la complication du code). Les bonnes questions sont plutôt: - as-tu bien un index sur (id_1,id_2) (un seul index qui contient les deux colonnes), et toute autre combinaison de colonnes déjà utilisée? - que donne un explain sur les requêtes en question? - combien y a-t-il de RAM sur ce serveur, et quel est la taille totale de la base (et éventuellement la partie "utile", i.e. celle qui est lue régulièrement)? - que donne la charge CPU, RAM, et accès disques de la machine? - mysql est-il correctement configuré au niveau buffers etc? - y a-t-il beaucoup d'accès en écriture sur cette table? - de quel type de table s'agit-il (myisam / innodb)? Je pars évidemment du principe que le serveur de bdd est dédié à cette tâche. Au delà, s'il y a plusieurs frontaux, avez-vous mis en place un cache partagé (memcache)? Jacques.

Il va falloir utiliser (directement ou indirectement) des cookies, ou une authentification HTTP. Mais comment paient-ils? Si tu utilises un système de micro-paiement, ce genre de fonctionnalité est souvent incluse d'office... Jacques.

Ou tout bêtement mettre des chemins absolus (qui commencent par "/") pour tes liens... Jacques.

Tu veux dire dans un script php? J'ai l'impression qu'il n'y a malheureusement pas de config globale possible (i.e. dans php.ini), donc tu es obligé de modifier ton code pour que tous les appels utilisent un context dans lequel le paramètre proxy va être réglé. Cf stream_context_create et stream_context_set_option. Jacques.

Euh... Le comportement normal d'Apache c'est d'être un serveur, donc s'il fait des connexions sortantes il faut nous préciser qui c'est qui les fait... mod_proxy? php? Autre chose? Ou alors je n'ai pas compris la question... Jacques.

Bizarre, normalement imagecolorallocate renvoie bien un nombre. Tu es sûr qu'il n'y a rien "sur le chemin" qui convertit ta couleur en cette valeur, ou quelque chose qui utilise la variable $noir pour y stocker '#000000'? Tu utilises quelle version de php? Ton image est truecolor ou palette? Jacques.

La combinaison que tu indiques n'est pas l'une des 3 que j'indiquais moi :-/ Et oui, c'est parfaitement normal que l'ordre des colonnes influe sur le résultat. Imagine un annuaire téléphonique classé par nom puis par prénom, et un autre classé par prénom puis par nom. Cherche tous les abonnés dont le nom est DUPONT. Lequel tu préfères? Le but est donc de voir comment tu penses qu'il est idéal qu'il exécute ta requête, et de lui donner les outils pour le faire. Là, en gros, il y a deux grandes options: - on commence par chercher les lignes de table2 qui correspondent à la zone donnée, puis on va chercher dans table les lignes correspondantes, on trie, et on limite, puis dans table3 les lignes correspondantes - on lit table dans l'ordre voulu, et on va vérifier pour chaque ligne qu'il y a une ligne dans table2 qui nous plait (avec la bonne zone), et la ligne de table3 qui va avec, jusqu'à ce qu'on en aie assez Les deux premières combinaisons d'index que je donnais correspondent à la première option, la 3e à la deuxième option. Jacques.

J'ai du mal à comprendre que tu aies pu avoir un succès, les NS de xname ne répondent toujours rien de pertinent pour ton domaine. Et comme je disais plus haut, si tu utilises un NS "à l'intérieur" de la zone qu'il sert, il faut un glue record, tu l'as bien ajouté? Jacques.

Oui, une clef primaire implique un index. Si tu as une clef primaire sur (id,lang) ou (lang,id) ça suffit. Le deuxième devrait être un poil plus rapide dans le cadre de cette requête-là (question d'agencement de l'arbre). Jacques.

Tu as essayé les 3 combinaisons d'index? Que donnent les explain dans les 3 cas? En ligne de commande en tous cas aucun souci pour créer un index sur deux colonnes dont l'une est la clef primaire. Jacques. (messages croisés) Si c'est très lent maintenant, c'est que tu as du supprimer un index vraiment utile, et ça devrait se voir dans l'explain... Jacques.

Pour une valeur donnée de table2.zone, il y a combien de lignes dans table et table2? Tu peux essayer: - index sur table2(zone) + index sur table(activ,id,prio,last_update) - index sur table2(zone) + index sur table(id,activ,prio,last_update) - index sur table2(id) + index sur table(active,prio,last_update) Dans tous les cas je pense qu'il te faut un index sur table3(id,lang) (ou lang,id qui sera probablement un poil plus rapide) Jacques.

Ca aiderait avec le schéma, on ne sait même pas dans quelle table sont prio et last_update... Avec une idée de la tailles des 3 tables, et de la "sélectivité" des tables/critères (par exemple savoir combien il y a de lignes dans table2 pour une valeur de table2.zone) ce serait encore mieux. Jacques.

Même réponse, mettre un index sur les deux colonnes utilisées (un seul index sur les deux, hein, pas un index sur chaque). Il faut aussi que l'ordre de tri (ASC/DESC) soit le même en général. Ceci dit, ta requête, elle ne retourne pas les 150 000 lignes je suppose? La partie importante c'est surtout les index qui correspondent aux clauses WHERE, donc tu peux avoir besoi d'avoir ces colonnes-là + les colonnes de tri dans ton index. Ce serait évidemment plus facile si tu nous indiquais ta requête et ton schéma (et le résultat d'un explain). Jacques.

Le problème c'est a priori que les serveurs de xname n'arrivent pas à récupérer ta zone. Donc soit il te manque des IPs dans la config named, soit il y a un filtre (iptables?) qui l'empêche, ou quelque chose du genre. Quelque chose d'intéressant dans les logs (/var/log/messages en particulier)? Tant qu'un dig SOA savs-epilepsie.fr. _AT_ns0.xname.org (et pareil pour les autres NS) ne fonctionne pas, tu as un problèmes (les secondaires n'arrivent pas à récupérer la zone sur le primaire). Jacques.

- tu as bien indiqué ton primaire à xname? - il semblerait qu'il manque des IPs dans celles que tu autorises à transférer la zone (d'après la FAQ de xname) - tu utilises un NS à l'intérieur de la zone qu'il sert, ce qui requiert un glue record. Idéalement, évite de le faire Jacques.

Il vaut mieux utiliser une RewriteCond pour ça. Si les .htm en question sont de "vrais" fichiers, une condition sur %{REQUEST_FILENAME} et -f par exemple devrait faire l'affaire. Sinon tu peux faire quelque chose comme RewriteCond %{REQUEST_URI} !\.htm$ par exemple. Jacques.

Ben un tri sur X desc c'est la même chose qui tri sur -X asc. Donc si tu veux changer d'ordre de tri, dans un cas tu multiplies par 1 et dans l'autre cas par -1... Jacques.

Oui, pardon, un huissier (légalement, un "officier ministériel"). A partir du moment où il y a tirage au sort, le dépôt d'un règlement est obligatoire (article L121-38 du code de la consommation). Il y a d'autres obligations dans les articles alentour du code de la consommation, je t'invite à les consulter sur www.legifrance.gouv.fr. Jacques.

Ben oui, CR et LF sont des caractères (presque) comme les autres, en tous cas si tu ne les prévois pas dans ta regex, ils ne peuvent pas être autorisés. Premier conseil: utilise preg_* au lieu de ereg*, ces dernières étant considérées comme obsolètes. Une fois que tu utilises preg_*, tu peux utiliser les flags s et m pour contrôler la façon dont les CR et LF sont considérés (i.e. si "." les autorise aussi et/ou si ^ et $ en tiennent compte ou pas). Tout ça est expliqué ici: />http://uk3.php.net/manual/en/reference.pcre.pattern.modifiers.php Jacques.

(SELECT 1 as tri,titre_event, date_event from tab_event WHERE date_event >= '10/05/29') UNION (SELECT -1,titre_event, date_event from tab_event WHERE date_event < '10/05/29' ) ORDER BY tri DESC,tri * date_event LIMIT 0, 100 Jacques.

Il n'y a qu'en essayant que tu sauras... Mais pour qu'un encadré de 4cm x 5cm te ramène du trafic, il va falloir être percutant, et en particulier avoir un bon nom de domaine (et éventuellement ses déclinaisons s'il peut y avoir un doute), que tu apparaisses bien en tête des résultats Google quand ont tape le nom de ton site (ou des déclinaisons)... Jacques.

Tant que c'est (complètement) gratuit pas de souci. Tu peux avoir besoin de déposer un règlement chez un notaire, cependant... Pour les pubs, on va supposer que tu n'incites personne (directement ou indirectement) à cliquer sur les pubs si les régies ne t'y autorisent pas. Jacques.

Si l'utilisateur doit payer pour jouer, c'est une loterie: - c'est ouvert au public - il y a espérance de gain - il y a sacrifice financier - il y a intervention du hasard Dans ce cas c'est interdit. Pour que ce soit autorisé, il faut supprimer l'un des 4 critères. Jacques.

Tu as de l'UTF-8 qui a été passé à htmlentities en lui disant (implicitement ou explicitement) que c'est de l'ISO. Enlève tout bêtement le htmlentities et ça devrait fonctionner tout seul. Jacques.