2015-12-12 5 views
0

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

idPerson  |  idPlace  |  nbTimesPersonWent | nbTimesPersonAWent 
    10  |  1   |   3    |  10 
    11  |  2   |   1    |  22 
    12  |  1   |   11    |  10 
    13  |  3   |   8    |  2 

Что я борюсь с находит, какой из этих idPerson является «лучшим» лицо рекомендовать А.

Есть ли способ (предпочтительно чистый SQL), сортировать эту таблицу с "ближе" значение nbTimesPersonWent и nbTimesPersonWent до "менее близких" значений?

+0

У вас есть два столбца с именем nbTimesPersonWent, это предназначено, если да, в чем разница? –

+0

Приятный глаз, я набрал слишком быстро, только что отредактировал свой ответ – Rogue

+0

Немного непонятно, какова цель. Предположим, что место '1' было посещено' 3' раз человеком 'B1' и' 3' раз лицом 'A', т.е. их предпочтение к месту' 1' равно, что может быть выражено '0 = | 3 -3 | 'С другой стороны, предположим, что место' 2' было посещено '100' раз человеком' B2' и '12' раз для человека' A'; их предпочтение к месту '2' отличается, но шансы встретиться были бы потенциально« 12 = мин {100,12} ». Является ли лицо 'B1' или лицо' B2' лучшим совпадением для 'A'? – Codor

ответ

1

Я бы рекомендовал использовать следующие таблицы

Person:

id 

Место:

id 

визит:

person_id, place_id, time_spent 

Теперь вы должны выбрать, какой путь вы будете s которые интересны конкретному человеку a.

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

f(a,b) = Sum of min_time(a,b,p) for all places p that both a and b have visited, где min_time(a,b,p) = minimum of the time a and b have spent at place p

f(a,b) = The number of places that both a and b have visited

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

Если вы можете указать точные критерии ранжирования, я буду рад помочь вам написать запрос на него.

ОБНОВЛЕНИЕ: Ниже приведен пример сортировки по критериям 2-го ранжирования. То есть по количеству посещенных мест: sqlfiddle.com/#!9/b56745/1/0

+0

В моем конкретном случае время, потраченное в данном месте, не совсем уместно, короткая история о том, как играть в игры в местах, поэтому все люди будут тратить примерно то же самое время. Второй на самом деле именно то, что я хочу, тем более обычное место у вас есть, тем лучше reccomandation – Rogue

+0

@Rogue Я бы не рекомендовал иметь таблицу для каждого пользователя, которая хранит всех других пользователей, если нет веских оснований для этого так. Если у вас есть n пользователей, для этого потребуется n таблиц, каждая из которых содержит n-1 элементов. Это примерно n^2 записи с большим количеством избыточности. Я привел пример того, как я буду создавать такую ​​систему здесь: http://sqlfiddle.com/#!9/b56745/1/0 Запрос находит всех других пользователей, кроме одного с id = 3, и оценивает их в порядке убывания посещаемых общих мест. –

Смежные вопросы