Jump to content

Spidetra

Hubmaster
  • Content Count

    326
  • Joined

  • Last visited

Everything posted by Spidetra

  1. Merci pour vos infos. Les différentes modifs ne marchent pas. Et comme ce n'est pas mon site, pour l'instant, je n'ai pas accés aux fichiers de logs. Voici le .htaccess en entier : Options +FollowSymLinks RewriteEngine On RewriteBase / RewriteRule ^(.*)-p-(.*).html$ product_info.php?products_id=$2&%{QUERY_STRING} RewriteRule ^(.*)-c-(.*)/$ index.php?cPath=$2&%{QUERY_STRING} RewriteRule ^(.*)-m-(.*)/$ index.php?manufacturers_id=$2&%{QUERY_STRING} RewriteRule ^(.*)-pi-(.*).html$ popup_image.php?pID=$2&%{QUERY_STRING} RewriteRule ^(.*)-t-(.*).html$ articles.php?tPath=$2&%{QUERY_STRING} RewriteRule ^(.*)-a-(.*).html$ article_info.php?articles_id=$2&%{QUERY_STRING} RewriteRule ^(.*)-pr-(.*).html$ product_reviews.php?products_id=$2&%{QUERY_STRING} RewriteRule ^(.*)-pri-(.*).html$ product_reviews_info.php?products_id=$2&%{QUERY_STRING} RewriteRule ^(.*)-i-(.*).html$ information.php?info_id=$2&%{QUERY_STRING} RewriteRule ^(.*)-links-(.*).html$ links.php?lPath=$2&%{QUERY_STRING} RewriteRule ^index.php$ / [QSA,L,R=301] Pour la dernière règle j'ai testé toutes les modifs conseillés ici. C'est fou, cette règle est toute simple et en plus elle marche sur mon poste en local
  2. Salut à tous, J'ai un .htaccess avec un ensemble de règle de réécriture qui fonctionnent en local et chez Ovh. J'ai rajouté une dernière règle pour rediriger index.php => / RewriteRule ^index.php$ / [QSA,L,R=301] ça marche très bien en local, mais pas chez Ovh. Quelle est la bonne syntaxe pour rédiriger index.php vers la racine du site ? merci pour le coup de main.
  3. J'ai eu la réponse, elle est pas complète donc j'espère que cela suffira : - Débit à l'expédition : Plus simple à la caisse d'épargne / société générale. A la société générale, la transaction était ré-initialisé après 15 jours. Donc pour pas avoir de pb, il vaut mieux que l'expédition ai lieu au maximum dans un délai de 15 J. Avantage à la caisse d'épargne. A la caisse d'épargne, le montant réservé pour un débit à l'expédition était de un euro. Cette pratique pouvait poser des pb de plafond pour les commandes importantes. A la société Générale ( Atos en Général ), le montant de validation était égal au montant de la transaction. Avantage Atos. - Trois fois sans frais : Cela devrait être possible sur tout système Atos. Je répond au conditionnel puiqu'apparemment ce n'est pas possible au Crédit Agricole. Va peut-être falloir passer en mode Guelante et Demande d'Explication auprès de ta banque
  4. je pose les questions qui vont bien, et je reviens pour te donner les réponses.
  5. Caisse d'épargne : SPPLUS : mauvaise expérience. Société générale : SogenActif ( Atos ) : Bonne expérience. ça dépend aussi de ton volume de transaction journalière. Les process de la caisse d'épargne était un peu trop "artisanaux" à mon goût. Teste en +sieurs pour te faire une idée.
  6. Quand on parle de base de donnée, généralement on fait allusion aux SGBDR. R voulant dire : relationnel. Donc pour toutes les appli faisant appel à des modèles Relationnels, il est normal que Google et les autres fassent appel à des SGBDR. Concernant, le moteur de recherche lui-même : 1. Les données ne sont plus relationnelles 2. N'importe quel SGBDR serait à la ramasse Le stockage des données pour les outils de recherches se fait dans des structures que l'on nomme : Inverted Index.
  7. C'est ce point qui me surprend ! Je n'utilise jamais d'index FULLTEXT, mais à priori, j'aurai envie de dire que ce genre de recherche est assez souple pour résoudre tes problèmes. Tu aurais un exemple de recherche que tu arrive à faire avec un LIKE, et pas avec une recherche FULLTEXT ? Si tu poste la structure de ta table, un petit jeu de donnée et les recherches qui posent un pb avec LIKE, on pourra s'amuser à essayer de t'aider. Les requêtes en FullText me semblent quand même assez souple ( petit extrait du manuel ) :
  8. En fait, comme dit un plus haut, je ne comprend pas vraiment le pb de Mamat. Je dois être un peu trop psycho-rigide FULLTEXT => Match AGAINST. Concernant les LIKE, l'optimisation relève du parcours du combattant. Je ne suis même pas surs qu'il soit possible d'optimiser des requêtes LIKE. En fait, je dois avouer que j'utilise très peu souvent LIKE, si possible jamais. La réponse au pb de Mamat a été donné par le premier post de Vincent. Ce qui en veut pas dire que le reste de la discussion soit inutile. Bien au contraire Je vois que l'on partage la même conception des choses Le nbr de prise de becs que j'ai pu avoir avec des developpeurs pour leur imposer le modèle intervallaire ! Je me sentirais moins seul Mais là on est en train de dériver du post initial
  9. Je me rend compte que j'ai été trop catégorique dans mon précédent post. En fait il faut remplacer ON par JE. Je ne cherchais pas à imposer des pratiques, juste à décrire les miennes. C'est la mise en production qui impose les pratiques d'optimisation. Je m'impose un certains nbrs de règles d'otimisation que j'applique systématiquement. Et non, je ne suis pas tjrs d'accord avec les manuels, désolé Ces règles sont issus de mon expérience, de ma connaissance des SGBD ou de le littérature. Parmis ces règles : je ne met jamais un index sur un champ de type TEXT. Tant pis si je ne suis pas d'accord avec le manuel. Mon cycle d'optimisation est assez simpliste : 1. Je conçois mon modèle en m'imposant des règles strictes. 2. J'optimise en phase de dév, en fct° des requêtes dont j'ai besoin. Cette optimisation va porter essentiellement sur : => La syntaxe des requêtes SQl => L'ajout de nouveaux index. 3. Je met mon modèle à l'épreuve de la production. C'est en recherchant les goulots d'étranglement que je vais mettre à l'épreuve mes règles initiales et les faire évoluer. Ensuite, il est vrai que dans mes choix je ne suis pas tjrs d'accord avec la majorité des développeurs. Mais ça c'est pas très grave. Deux exemples concret de choix techniques où je ne suis pas d'accord avec la grande majorité des développeurs : - L'indexation FULLTEXT : Je n'utilise jamais un SGBD, pour les recherches FULLTEXT. J'estime que les systèmes ne sont pas assez performant. - La modélisation d'une arborescence : je ne modélise jamais une arborescence par auto-jointure ( Merci, M. Celko ) . Tant pis, si la grande majorité des développeurs choisissent systématiquement le modèle par auto-jointure et ne sont pas d'accord avec moi.
  10. Cela n'est pas une bonne idée. En règle générale, on n'utilise jamais d'index FULLTEXT, on utilise des index. On ne met jamais d'index sur un champ de type TEXT ou sur un BLOB. Si on veut indéxer un champ de type TEXT, on utilise FULLTEXT et des requêtes du type MATCH...AGAINST. Le fait de doubler ( Index + FULLTEXT ) sur la même colonne ne sert à rien. C'est peut-être même contre-performant. L'optimisation dépend de l'utilisation que tu fait de la colonne dans tes requêtes.
  11. Désolé, je n'ai donc absolument rien compris à ton pb.
  12. Nous utilisions des développement en interne.
  13. Ton index ce n'est pas un index FULLTEXT ? Pourquoi ne pas dropper ton index actuel et le remplacer par un index fulltext. Ensuite tu refais un explain pour t'assurer qu'il est bien utiliser. Les index ne sont pas systématiquement utilisé. D'ailleurs je ne suis pas sur qu'ils soient utilisé avec des requêtes de type LIKE et %. Je fait un copier/coller d'un post que je viens de faire en face
  14. Salut, Je viens juste de me rendre compte que tu avais posté ton schéma. J'ai jeté un coup d'oeil ( je dois avouer un coup d'oeil rapide ), ça à l'air bc plus correct que la première fois. Tes noms de clés étrangères sont parfois un peu long à mon goût ( domaine_utilisateur_profil_id_profil ), mais bon c'est pas très grave.
  15. Spidetra

    message d'erreur

    il faudrait tester ta variable RecordId pour t'assurer que le paramètre est bien passé. Tu as un lien vers le script que tu utilises ? Je jetterai un coup d'oeil
  16. Spidetra

    message d'erreur

    Ton pb n'est pas au niveau SQL mais bien au niveau Php : $recordID = $_GET['recordID']; La réception du paramêtre recordID n'est pas testé. Je suis pas un spécialiste de l'injection SQL, mais j'ai pas l'impression que l'appli soit trés sécurisé. Imaginons le bout de code suivant : /lapage.php?recordID=1;DELETE * FROM inscription => Suppression de 10 enregistrement dans la table inscription.
  17. Spidetra

    message d'erreur

    la requête porte sur la table inscription. Le champ auquel tu fait référence est dans la table an_membre. Avec une erreur sur le champ l'erreur serait plutôt du type : Unknown column 'idmembre' in 'field list' en tout cas le bout de code php, ça sent fortement le pager automatique généré par dreamweaver si tu t'y connais en php tu pourrais peut-être afficher las requête sur ta page et nous la poster : mysql_select_db($database_connexion, $connexion); $recordID = $_GET['recordID']; $query_DetailRS1 = "SELECT * FROM inscription WHERE id_membre = $recordID"; $query_limit_DetailRS1 = sprintf("%s LIMIT %d, %d", $query_DetailRS1, $startRow_DetailRS1, $maxRows_DetailRS1); $DetailRS1 = mysql_query($query_limit_DetailRS1, $connexion) or die(mysql_error()); $row_DetailRS1 = mysql_fetch_assoc($DetailRS1); Il faut juste rajouter ce bout de code : echo $query_limit_DetailRS1; avant : $DetailRS1 = mysql_query($query_limit_DetailRS1, $connexion) ....
  18. Spidetra

    message d'erreur

    Tu pourrais poster la requete qui pose pb ?
  19. Un début de réponse sur les requêtes multi-base dans ce post http://www.webmaster-hub.com/index.php?showtopic=23124&hl=
  20. On discutait justement de ça hier apm. Il semblerait que cela existe chez Oracle. Sinon, comme le dit Anonymus, il faudrait écrire un parser générique faisant le mapping entre les "types" XML et les types SQL. Cela a de l'intérêt si les données de tes flux XML ont une struture relationelle.
  21. En terme de performance quasiment aucune. Les optimiseurs SQL font bien leur boulot aujourd'hui. Par contre il existe une différence de sens - count(*) : compte la cardinalité d'une table. Le nombre de ligne de la table ou de la requête. Sauf erreur de ma part, c'est ce que voulait faire Tizel. Donc je lui ai conseillé de mettre count(*) - count( [DISTINCT|ALL] expression ) : Compte le nombre d'expression connu. Donc, après avoir enlevé les valeurs NULL. - Sur une clé primaire : count(*) et count(primary_key) sont strictement équivalent. Par habitude, je m'impose comme règle d'utiliser count(*) si je veux compter les lignes et pas count(primary_key)
  22. Ma réponse est fausse les GROUP BY ne sont pas autorisés dans les UPDATE. Elle me plaisait pas trop cette requête UPDATE [LOW_PRIORITY] [IGNORE] tbl_name SET col_name1=expr1 [, col_name2=expr2 ...] [WHERE where_condition] [ORDER BY ...] [LIMIT row_count] Fait deux requêtes : - Un SELECT pour récupérer ton count(*) - Ton update derrierre
  23. tu fait un count() sans faire de group by. Note : faire un count(*) plutot que count(nom_de_champ) Un truc du style, sans aucune garantie. : UPDATE dc_post, dc_comment SET nb_trackback=count(dc_comment.nb_trackback) WHERE dc_comment.comment_pub=1 & dc_comment.comment_trackback=1 & dc_comment.post_id=dc_post.post_id GROUP BY dc_comment.post_id
  24. ça c'est une bonne nouvelle.
×
×
  • Create New...