Je travaille actuellement pour un site de réseautage social.Structure de la base de données pour l'enregistrement des résultats de recherche
Mon patron a récemment eu l'idée d'afficher les résultats de la recherche par des résultats aléatoires plutôt que normaux (date d'enregistrement). Le problème avec cela est simple et évident: si vous passez d'une page à l'autre, cela va vous montrer des résultats différents à chaque fois que la liste est randomisée à chaque fois.
J'ai eu l'idée de stocker les résultats dans la base de données + les cookies quelque chose comme ceci:
- Cookie contenant une version sérialisée de la demande $ _POST (nécessaire si nous voulons faire une re-tri)
- Une table qui servira de base pour la recherche id => recherches (id, utilisateur
_id, creation
_DATE) - Une table qui stockerait les résultats et leur ordre => recherche
_results (search_id, order, user
_id)
Diagramme ressemblerait à quelque chose comme ça:
- Après chaque recherche je stocke le « où » dans un cookie ou d'une session
- Puis-je effacer la recherche précédente dans « recherches »
- Puis-je supprimer résultats précédents dans « searches_results »
- Puis-je insérer une ligne dans « recherches » pour la clé
- Puis-je insérer chaque ligne d'utilisateur dans « searches_results »
- Et enfin je redirigent l'utilisateur vers somethink lik e? search_id = [search_key]
Il y a un gros défaut ici: les performances .... il est définitivement possible de faire baisser le système OU très lentement.
Une idée de ce qui serait le meilleur pour structurer cela?
Hum qui pourrait faire l'affaire. Je vais devoir vérifier comment MySQL réagit à cela. (Merci pour le commentaire-conseil Je suis habitué à des forums non-threadés – Erick