Структура базы данных для сохранения результатов поиска

Question

Я сейчас работаю на сайте социальной сети.

У моего босса недавно возникла идея показывать результаты поиска случайным образом вместо обычных результатов (дата регистрации). Проблема в этом проста и очевидна: если вы переходите с одной страницы на другую, она будет показывать вам разные результаты каждый раз, когда список будет случайным образом каждый раз.

У меня была идея сохранить результаты в базе данных + файлы cookie примерно так:

• Файл cookie, содержащий сериализованную версию запроса $ _POST (необходим, если мы хотим выполнить повторную сортировку)
• Таблица, которая будет служить основой для поиска id => search (id, user _id, creation _date)
• Таблица, в которой будут храниться результаты и их порядок => поиски _results (search_id, order, user _id)

Блок-схема будет выглядеть примерно так:

• После каждого поиска я сохраняю «где» в файле cookie или сеансе
• Затем я стираю предыдущий поиск в «поисках»
• Затем я удаляю предыдущие результаты в "search_results"
• Затем я вставляю строку в «поиски» для ключа
• Затем я вставляю каждую строку пользователя в "search_results"
• И, наконец, я перенаправляю пользователя на что-то вроде? Search_id = [search_key]

Здесь есть большой недостаток: производительность .... определенно возможно сделать систему ИЛИ выключить ИЛИ очень медленную.

Есть идеи, что лучше всего структурировать?

Answer 1

Что если вместо упорядочения в произвольном порядке вы упорядочиваете какую-то функцию, где порядок известен и повторяется, просто неочевиден? Вы могли бы заполнить такую ​​функцию некоторыми данными из поискового запроса, чтобы сделать ее еще менее очевидной, чтобы она повторялась. Таким образом, вы можете перелистывать свои результаты вперед и назад и всегда получать то, что ожидаете. Музыкальные проигрыватели используют такую ​​функцию для своей функции случайного воспроизведения (так что если вы нажмете назад, вы получите предыдущую песню, и если вы нажмете кнопку далее, вы вернетесь к тому, с чего начали). Я уверен, что вы можете угадать некоторую функцию, чтобы выполнить это ... побитовое XORing значения ID с некоторой константой (из запроса), а затем сортировка по полученному числу может быть достаточной. Я выбрал XOR произвольно, потому что это тривиально простая функция, которая даст вам повторяемые и неочевидные результаты.

Answer 2

Ну, я с Мэттом спрашиваю: «Почему?»

Думаю, у rmeador тоже есть хорошее предложение. Вы можете случайным образом отсортировать по другому полю или алгоритму. Только из перестановок DESC / ASC в последнее обновленное или какое-либо другое поле результата.

Другой вариант заключается в том, чтобы выполнить первоначальный поиск в первый раз и вернуть только связанные идентификаторы, а затем сохранить строку полного идентификатора в базе данных, после чего каждая последующая страница будет искать эти идентификаторы.

Мои два цента.

Я вижу сценарий, в котором рандомизированный набор результатов полезен, но не для поиска, а для просмотра профилей, исполнителей или локальных событий. Он предлагает больше возможностей для тех, кто не будет отображаться в традиционно направленном поиске.

Answer 3

Извините, я знаю, что это не помогает, но я не понимаю, почему ваш босс хотел этого?

Я знаю, что если я ищу человека в социальной сети, то хочу, чтобы результаты упорядочивались только по релевантности и релевантности. Я думаю, что рандомизированные результаты будут разочаровывать пользователя, но, возможно, это только я.

Например, если я ищу «Джон Смит», то первым первым пакетом результатов будут люди по имени «Джон Смит». Тогда покажи мне похожие имена в конце результатов. Я не хочу искать «Джона Смита» и получать «Джона Смитерса» как мой второй результат.

Answer 4

Хм, может быть, но разве оператор xor не говорит только, является ли он ИЛИ эксклюзивным? Я имею в виду, что здесь нет математической операции, насколько я знаю.