Système de réécriture d'URL (URL Rewriting)

Les systèmes de réécriture d'URL posent rapidement des problèmes de scalabilité pour un site générant un trafic respectable (genre dès 1000 visiteurs uniques par jour). Je l'ai déjà exprimé dans un précédent article : Mambo 404 SEF, et souhaite maintenant apporter un design de solution.

Une technique relativement simple pour palier à ce problème de VARCHAR non- ou mal -indexable est d'introduire une variable aléatoire dans l'URL, variable à partir de laquelle la vrai URL sera chargée : www.domaine.com/14523623423/news/ma_premiere_news.html
L'important dans cet URL est donc la variable 14523623423, alors que ce qui se situe après n'a aucune importance et peut être modifié à souhait (on remarque aussi ici que cette technique permet rapidement de mettre un place de l'URL flooding, utilisants des URLs de toute sorte pour pointer sur la même page. Attention à ne pas en abuser, car on risque de voir son site se faire bannir des moteurs de recherche).

La requête SQL devient donc

SELECT realurl FROM redirections WHERE urlid = 14523623423

Mieux ça non ? Le problème évoqué ici est en fait global à tout design de base de données : les champs utilisés sans intervention d'un utilisateur dans une condition devraient toujours être de type entier ou un dérivé. Car même si les chaines de caractères sont relativement rapide lors des tests, la réaction à haute charge est très souvent mauvaise...