- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Создал топик с целью уточнить верно ли я рассматриваю алгоритм создания "тегов". В итоге должно получится что-то вроде beta.ya.ru
Для тех кто не знает, там при вводе в профиле своих увлечений, роста, возраста - выводится циферка - количество совпадений этих данных с другими юзерами.
Итак, мой вариант реализации оного:
Предположим в профиле есть 3 поля:
Увлечения (поле fav) - содержит увлечения через запятую
Хобби (поле hob) - содержит хобби через запятую
возраст (поле age) - содержит возраст юзера.
Итак есть у нас 10000 юзеров.
Моя идея заключается в создании таблицы tags, которая состоит из полей:
tag - тег (слово)
type - тип тега (к какому полю относится: Увлечения, Хобби или Возраст)
value - количество совпадений
При добавлении информации в профиль - в таблицу профиля все данные вводятся "как есть", а для таблицы с тегами все теги делятся на массивы (если слова введены через запятую) и соответственно добавляются каждый отдельно. Если есть совпадения с данным тегом - значит новая строка не добавляется, а лишь value соответствующей строки увеличивается на 1, если же нет, то создается новая строка с новым тегом и значением value=1
При отображении информации в профиле. Идёт один запрос в таблицу с тегами где теги профиля сверяются с тегами в таблице и делается вывод циферки возле каждого слова.
С товарищем возник спор на тему необходимости создания отдельной таблицы с тегами. Моё мнение, что она необходима даже только по тому, что некоторые поля содержат не одно слово а слова через запятую, при этом количество совпадений необходимо выводить для каждого из них.
ЗЫ: Обновление таблицы с тегами также можно делать кроном ночью. Чтобы скрипт сам составлял статистику каждый день и всё. Дабы не грузить его запросами во время большого количества юзеров онлайн.
Если я не прав, скажите пожалуйста в чём :) Если прав - тоже скажите.
Спасибо!
Зачем хранить данные, которые можно вычислить? :) Так быстрее? А кто сказал, что это - узкое место? Не стоит оптимизировать еще не написанный код ;)
Навскидку за 15 минут придумал что-то такое.
Имеем 3 таблички - fields, values, и profiles, последняя устанавливает связь "пользователь - параметр - значение". Выбираем все параметры, для которых пользователь №1 указал хотя бы одно значения, и кол-во пользователей, указавших такое же значение:
Получаем что-то вроде:
Остается в цикле обработать повторяющиеся параметры. При подсчет колонки "more" идет поиск по табличке, состоящей из трех числовых столбцов - подозреваю, что здесь узкого места возникнуть не должно. Даже если каждый пользователь заполнит по 10 значений для 10 параметров, мы получим вполне приемлимый миллион записей :) Поиск по текстовым полям (и то, типа VARCHAR) идет только при изменении профиля, что бывает не слишком часто.
Обратите внимание, параметры не фиксированные - можно добавить собственный параметр с собственным же значением, в случае ya.ru это реализовано как "Особенное". Собственно, попробуйте поизучать, какие еще выборки реализованы в ya.ru, примеряя на свою модель - увидите, где могут возникнуть проблемы.
Задумывайтесь об оптимизации, только когда столкнетесь с неприемлемой производительностью (для этого не нужно ждать реальной нагрузки, можно выявить тестами на фиктивных данных), и только когда найдете узкое место. И я лично стал бы нарушать целостность данных только в случае, когда ни один другой способ (как то кэширование страниц / выборок) не подходит.
Действительно решение уникальное :)
Я просто синтаксис ещё не настолько изучил, чтобы столь сложные запросы писать :)
Спасибо большое за подсказку!