>>6430
H2O
Kanon
Fruit Basket
Iriya no Sora
REC
School Days
Toradora
Working

>>6431

>весёлое, немного романтики
>School Days

Кстати, меня давно терзает вопрос, возможно ли как-то кроме указания конкретных жанров или каких-нибудь безумных тегов формировать, и в дальнейшем обрабатывать расплывчатые запросы, когда хочется чего-то но не понятно, чего конкретно? Т.е. "Хочу посмотреть вот что-то такое ${расплывчатое перечисление типов, которые пересекаются}". Думал о каких-то similar, но это опять же не совсем то, да и опять же, нужно обладать нехилым количеством тайтлов, да и вкусы должны быть подобны.

>>6432
Можно попытаться формиовать запросы как "что-то похожее на %animename%". Можно перечислить что понравилось и что не понравилось и попросить подобрать что-то, что могло бы понравиться.

>>6433
Что-то похожее это скорее ближе к similar, для которого требуется значительно большой вклад в базу, и опять же вкусы(он считает, что нарута == хлорка, я - нет). А вот второе уже более реализуемо и практично, можно на основе нужных тайтлов выбирать жанры, количества эпизодов, использовать на них статистику и получать какие-то более менее близкие результаты. Правда, нужны какие-то рейтинги, которые немного расходятся с концепцией и им никак не находится места.

>>6434
Можно поступить проще - создать базу списков понравилось/не понравилось (или индивидуальных рейтингов), дальше при запросе искать в базе максимально близкий список, и из него советовать то, чего не было в исходном запросе.

>>6436
Как-то мне кажется, что это совсем не проще, но в принципе тоже подойдет, наверное.
Все равно, так не хочется делать рейтинги(хотя это всего лишь +1 поле в базе), однако в них постоянно какая-то неуловимая необходимость. С другой стороны, их же можно не собирать в одну статистику, да и вообще никому не показывать.

>>6437

> Все равно, так не хочется делать рейтинги(хотя это всего лишь +1 поле в базе)

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

>>6438

>свой список просмотренных им тайтлов

Это как бы суть проекта, так что это все есть с самого начала.

>ищутся наиболее близкие к его вкусам люди

Вот это одна из ненавистных мне сторон социальных сетей, когда кто-то решает кого мне фолловить/на кого ориентироваться. Проблемы у меня обычно возникают больше идеологические, чем с реализацией, вот и здесь также. Хотя, с другой стороны, это ведь не будет видно совсем. Насколько я сейчас, ночью, вижу, там запрос:
SELECT anime_id, COUNT(*) as acnt FROM anime_userstatusbundle WHERE rating > 7 AND user_id IN (SELECT user_id, COUNT(*) as cnt FROM anime_userstatusbundle WHERE user_id != $userid AND anime_id IN (SELECT anime_id from anime_userstatusbundle where rating > 7 and user_id = $userid) GROUP BY user_id ORDER BY cnt DESC LIMIT 3) GROUP BY anime_id ORDER BY acnt DESC LIMIT 3; выбор тайтлов по нужным жанрам, если надо, +дополнительный джойн. Тяжеловато как-то получается, хотя и не слишком, зависимо от мускула, да и на орм эту штуку трудно переложить. Запрос наверное не сработает, и еще мне кажется, что один подзапрос там лишний, но как-то так.
Меня похоже занесло, и я все-таки написал запрос, хотя не хотел.

>>6436
Для этого есть MAL. Рекоммендации в нём временами упоротые, но если с кем-то >70% сходства при паре сотен общих тайтлов, стоит зафрендить и следить за хистори. Ещё на нём удобно заполнять список to watch пока бродишь по всяким /a/ и когда потом возникнет вопрос что посмотреть попробовать для начала выбрать из этого списка. Пользователей MAL-а почему-то считают тайтлодрочерами, но на самом деле он просто удобен и помогает искать что бы посмотреть, плюс удобно следить за онгоингами и находить тайтлы из одной вселенной. Это, как нетрудно догадаться, реклама списков.

>>6439

> Вот это одна из ненавистных мне сторон социальных сетей, когда кто-то решает кого мне фолловить/на кого ориентироваться.

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

> Насколько я сейчас, ночью, вижу, там запрос:
> SELECT anime_id, COUNT(*) as acnt FROM anime_userstatusbundle WHERE rating > 7 AND user_id IN (SELECT user_id, COUNT(*) as cnt FROM anime_userstatusbundle WHERE user_id != $userid AND anime_id IN (SELECT anime_id from anime_userstatusbundle where rating > 7 and user_id = $userid) GROUP BY user_id ORDER BY cnt DESC LIMIT 3) GROUP BY anime_id ORDER BY acnt DESC LIMIT 3;

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

>>6440
Для этих целей никто не мешает рипнуть MAL.

>>6440
Мал - убогая неудобная помойка, полная социального говна, которое совсем не нужно при ведении личных списков аниму. Приложение, написанное под себя, где тайтл добавляется в любой лист в 2 клика, при этом лист становится наглядно раскрашенным, намного удобнее.
Кстати, да, про релейтед, наиболее удобно, на мой взгляд оно сделано на вротарте, когда видно полный список связанных прямо из тайтла(правда связки их порой безумны), на мале, как и на анидб, и на анн(но там чуть получше, иногда видно больше) из тайтла весь релейтед не видно, нужно либо ходить по каждому связанному тайтлу, либо по списку, в котором не видно статуса. На анидб еще есть достаточно няшная графичекская схема, но когда-нибудь я доберусь и до этого.