Quelle est la meilleure méthode pour encoder ses URLs ?

Bonjour à toutes et à tous.

Depuis un petit moment je suis responsable web et ai totalement refait le site web pour le sortir du CMS Dolphin.

Récemment, j'ai attaqué plus sérieusement la réécriture d'url. J'ai déjà des URLs style monsite.com/catégorie.html, mais la, il s'agit d'avoir des URL dont les paramètre permettrons de faire des recherche en base de données.

Pour vous mettre dans le contexte, j'ai à disposition un catalogue de randonnées. Avec l'URL monsite.com/randonnees/france/corse/ j'obtiens toutes les rando de corse en france.
Pas de problème jusqu'à que le nom de la région soit Provence alpes cote d'azur.

J'utilise un fonction pour encoder les url qui permet de supprimer les accents, espaces, caractères spéciaux etc... et formater l'url comme ceci provence-alpes-cote-dazur
idem pour les nom des randonnées: Belle-rando-dans-les-montagnes-de-france

Maintenant que j'ai mon provence-alpes-cote-dazur, je me demande comment faire pour le retrouvé en base de données.

Je pensais à:

- Soit trouver une fonction en SQL qui fait la même chose que celle que j'ai en PHP, que je n'ai pas encore trouvée.
- Soit avoir la correspondance des pays, region et nom de randonnées avec les valeurs encodées en base de données.

Je viens vers vous afin d'obtenir des conseils et éventuellement une solution. Je n'ai encore pas eu l'occasion de travailler avec des URL comme ça et j'avoue ne pas du tout avec de connaissance sur les bonne pratique a ce sujet.

Merci d'avance pour votre aide et votre lecture :)

Si on prend par exemple WordPress, chaque page a un champ "Titre" qui contient "Provence-Alpes-Côte d'Azur" et un champ "URL" qui contient "provence-alpes-cote-d-azur".
Cela permet, à partir de "http://site.com/provence-alpes-cote-d-azur" de faire une recherche sur "provence-alpes-cote-d-azur" dans la base de données et de trouver la page correspondante.

C'est une idée de faire comme wordpress, Je vais me pencher sur le sujet.
Sinon, j'avais l'idée de tout récupéré en base de données et en bouclant sur les résultats je peut testé l'encodage de la région par rapport à ma région passé en paramètre déjà encodée. Ca fait double travail pour le serveur, mais pas de modifs à faire en base sachant qu'il y en aurait pas mal à faire.

Salut,

Cela te ferait un peu de travail mais ce serait beaucoup mieux optimisé. Cela dit si tu n'a pas beaucoup de lignes ça peu s'envisager et ça devrait pas poser de problème mais il faut être certain que la table ne va pas trop grossir. Par exemple dans ton cas c'est envisageable sans problème pour la table des régions, mais pour la table des randonnées s'il y en a plusieurs milliers ou plus tu aurais intérêt à optimiser cette table pour les recherches en rajoutant un champ supplémentaire.

Après cela dépend aussi de la charge de ton serveur. Si tu n'attends pas beaucoup de connexions simultanées l'optimisation n'aura pas beaucoup d'importance (à moins d'avoir des tables très très grandes) même si tu gaspilles beaucoup plus de ressources. Le système de cache de plus en plus perfectionné avec les dernières versions de php pourra aussi compenser dans une certaine mesure. Donc c'est pas toujours obligatoire mais la solution donnée par mathieu est plus efficace et à privilégier si possible, ou sinon comme déjà dit il faut bien savoir où l'on va.

Du coup, je suis parti sur une table de correspondance département/département encodé. Et le nom encodé de chaques rando sera stocké à coté du nom. Ca me semble la meilleurs solution pas trop lourde.

Merci pour vos réponses !

Citation:

---

Envoyé par EclairOChocola

Ca me semble la meilleurs solution pas trop lourde.

---

Concernant les performances c'est certain.

D'autant plus que le nombre de colonnes importe peu dans la rapidité du traitement d'une requête. C'est principalement les jointures, le nombre de critères de recherches et surtout la longueur des tables qui font la différence.

Par ailleurs, en plus du fait qu'exécuter une fonction php sur chaque item dans ta table sera pénalisant, cela t'interdit également de mettre cette colonne comme index ce qui est doublement pénalisant. Il faudrait pouvoir faire une fonction "reverse_encodage()" et ne l'appliquer que sur le critère de recherche (pas sur les item de ta table) mais c'est pas toujours possible...

Donc logiquement si on veut optimiser le traitement serveur on a tout intérêt de rajouter si besoin des colonnes spécifiques pour accélérer les recherches :)