- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Нужно сохранять кучу огромной инфы сопутствующую пользователю - просмотренные фото, просмотренные страницы и т.д.
Кто и как решает эти задачи и хранит эту байду? хранить в таблицах -страшно подумать...:eek:
Кроме sql таблиц, как раз страшно подумать кто же будет это хранить..
хранить в таблицах -страшно подумать...😮
- как вариант: пихать данные в xml, а его уже хранить в таблице как текст (или таблицах - есть инструменты которые автоматически раскидывают данные из xml в таблицы)
- еще вариант: хранить данные в объекте который с помощью ORM автоматом мапится на базу
Esco, на какой срок вы сохраняете эти записи, как вы планируете их реализовывать, и о каких объёмах речь идёт, уточните плз.
хранить в таблицах -страшно подумать..
Верно, чаще всего - глупое решение
просмотренные фото, просмотренные страницы и т.д.
Такую инфу можно хранить в переменных сессии, эсли информация актуальна пока юзер на сайте.
Я предпочитаю хранить в виде образа переменных для пользователя. (т.е. есть файл с именем пользователя где лежит образ памяти всех его переменных) /я использую Perl/
Нужно сохранять кучу огромной инфы сопутствующую пользователю - просмотренные фото, просмотренные страницы и т.д.
Она уже хранится по умолчанию. В логах сервера... ;)
- как вариант: пихать данные в xml, а его уже хранить в таблице как текст (или таблицах - есть инструменты которые автоматически раскидывают данные из xml в таблицы)
ради чего нагружать и проц и файловую систему
PS Реляционные БД нужно использовать только тогда, когда это оправдано не только неумением использовать что-то еще
мои 5 копеек: создайте в php объект с нужными атрибутами, потом весь объект при помощи функции Serializable() превращаете всё в строку и сохраняете в одну яцечку таблицы, потом если надо очень бысто востанавливаете все данные юзера функцией unserializable()
Serializable() превращаете
сохраняете в одну яцечку таблицы
извениете, первая часть и "очень быстро" - не совместимо
Serializable() превращаете всё в строку и сохраняете в одну яцечку таблицы, потом если надо очень бысто востанавливаете все данные юзера функцией unserializable()
Линейкой по рукам за такое нужно :)
В зависимости от периода актуальности информации можно хранить либо в сессии, либо в базе, если с информацией нужно проводить работы типа выборки.
А так-то, очень даже хороший намёк дал СКОРПИОН.
а зачем объект создавать? что мешает сериализовать данные и хранить, массивы всякие прекрасно сохраняются в текст? serialize()
$user=array('path'=>array('p1','p2'),'time'=>x)