2009-01-21 11 views
1

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?

Répondre

1

Et si au lieu de commander au hasard, vous avez commandé par une fonction où l'ordre est connu et répétable, tout simplement non-évident? Vous pourriez graver une telle fonction avec certaines données de la requête de recherche pour que ce soit encore moins évident qu'elle se répète. De cette façon, vous pouvez faire défiler vos résultats et obtenir toujours ce que vous attendez. Les lecteurs de musique utilisent ce type de fonction pour leur fonction de lecture aléatoire (de sorte que si vous cliquez en arrière, vous obtenez la chanson précédente, et si vous cliquez à nouveau, vous êtes de retour là où vous avez commencé). Je suis sûr que vous pouvez deviner une fonction pour accomplir ceci ... bitwise XORing Les valeurs d'ID avec une certaine constante (de la requête), puis le tri par le nombre résultant pourrait être suffisant. J'ai choisi arbitrairement XOR parce que c'est une fonction trivialement simple qui vous donnera des résultats reproductibles et non évidents.

+0

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

0

Hum peut-être, mais l'opérateur xor ne dit que si c'est un OU exclusif? Je veux dire, il n'y a pas d'opération mathématique ici, autant que je sache.

+0

Mes excuses pour la confusion XOR est à la fois un opérateur logique et un peu au niveau des bits J'ai mis à jour ma réponse avec un lien vers une explication. , sur StackOverflow, afficher une réponse en réponse à une autre réponse est mal vu. Vous devez plutôt mettre à jour la question ou commenter une réponse. – rmeador

0

Désolé, je sais que cela n'aide pas, mais je ne comprends pas pourquoi votre patron voudrait cela?

Je sais que si je recherche une personne sur un réseau social, alors je veux que les résultats soient classés par pertinence et pertinence seulement. Je pense que les résultats aléatoires seraient frustrants pour l'utilisateur, mais peut-être que c'est juste moi.Par exemple, si je recherche "John Smith", alors le premier premier lot de résultats sera mieux nommé "John Smith". Puis montrez-moi des noms similaires vers la fin des résultats. Je ne veux pas chercher "John Smith" et obtenir "Jon Smithers" comme deuxième résultat.

0

Eh bien, je suis avec Matt en demandant "Pourquoi?"

Je pense que rmeador a aussi une bonne suggestion. Vous pouvez trier au hasard par un champ différent ou une sorte d'algorithme. Juste à partir des permutations de DESC/ASC sur la dernière mise à jour ou un autre champ de résultat. L'autre option consisterait à effectuer une première recherche la première fois et à ne renvoyer que les ID associés, puis à stocker la chaîne complète de l'ID dans la base de données et chaque page suivante serait alors une recherche par rapport à ces ID.

Mes deux cents.

Je peux voir un scénario où un ensemble de résultats randomisés est utile mais pas pour la recherche mais pour la navigation de profils ou d'artistes ou d'événements locaux. Il offre plus d'exposition à ceux qui ne se présenteraient pas dans une recherche orientée traditionnellement.

Questions connexes