- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть таблица пользвателей для самописного двига
Работа двига организована так, что к этой таблице пользователей идет обращение с 30 сайтов, где
один и тот же пользователь может иметь несколько разных статусов с различным времением их истечения,
пришла мысль о создании для каждого сайта (хоста) отдельного поля статуса. Таким образом, добавляется
30 полей `bb_status_1` text NOT NULL, `bb_status_2` text NOT NULL, и т.д.
1. Насколько такая структура таблицы скажется на производительности?
2. Каковы варианты организовать структуру таблицы пользователей по-другому, если для статуса bb_status должен соответствовать отдельный хост (сайт)?
Я бы создал отдельную таблицу для статусов. user_id | site_id | status как-то так.
ТС, 1 раз считывайте все статусы и впишите их в сессию или куки, пусть берутся оттуда данные и не надо дёргать БД каждый раз.
ТС, 1 раз считывайте все статусы и впишите их в сессию или куки, пусть берутся оттуда данные и не надо дёргать БД каждый раз.
А как же эта, как ее, безопасность? :(
А как же эта, как ее, безопасность? :(
Безопасность чего?! Мы тут про ВЫВОД информации, а не про запись. Пусть эти статусы в куках и всё. Сможет поменять из куков? Ну и куда он их поменяет? Для себя родного чтоли? Они же в базу не будут писаться.
Безопасность чего?! Мы тут про ВЫВОД информации, а не про запись. Пусть эти статусы в куках и всё. Сможет поменять из куков? Ну и куда он их поменяет? Для себя родного чтоли? Они же в базу не будут писаться.
Ну а кто ж его знает что там за статусы. Может там админ/не админ :)
Я бы создал отдельную таблицу для статусов. user_id | site_id | status как-то так.
BasePelleta, я бы сделал так же как Counselor
Статус пользователя непостоянный, следовательно, нужно будет создать поля: время присвоения статуса, время истечения статуса.
Значит, все-таки отдельная таблица статусов?
На данный мент поле `bb_status` text NOT NULL
имеет записи типа [Journalist-15600045430345], а в выводе имеем статус Journalist, который действительно передается в сессию, что позволяет избежать лишних запросов к базе.
Меня смущает тип поля - text, все-таки varchar 25 обрабатывалось бы быстрее?
В таблице 50.000 пользователей, если кол-во сайтов равно 30, то записей статусов в таблице должно быть 1 500 000, что, на мой взгляд, избыточно, ведь у большинства пользователей статус - Simple, статус Journalist, Profi и т.д. будет только у нескольки сотен пользователей. Какова будет структура в этом случае?
BasePelleta, для чего нужно число после названия статуса?
Быстрее обрабатывался бы CHAR(25)
Статус пользователя непостоянный, следовательно, нужно будет создать поля: время присвоения статуса, время истечения статуса.
Значит, все-таки отдельная таблица статусов?
На данный мент поле `bb_status` text NOT NULL
имеет записи типа [Journalist-15600045430345], а в выводе имеем статус Journalist, который действительно передается в сессию, что позволяет избежать лишних запросов к базе.
Меня смущает тип поля - text, все-таки varchar 25 обрабатывалось бы быстрее?
В таблице 50.000 пользователей, если кол-во сайтов равно 30, то записей статусов в таблице должно быть 1 500 000, что, на мой взгляд, избыточно, ведь у большинства пользователей статус - Simple, статус Journalist, Profi и т.д. будет только у нескольки сотен пользователей. Какова будет структура в этом случае?
Ну во-первых нужно заняться нормализацией БД. Т.е. сделать отдельную таблицу всевозможных статусов: status_id | status_text
А в таблицу пользователей записывать только числовое id - это сократит как размер БД, так и увеличит производительность.
А во-вторых если делать отдельную таблицу, в которую будут записываться пользователи и их статусы на разных сайтах, то можно (и нужно) статус по-умолчанию (Simple) туда не заносить, - только отличные от него статусы. И при выборке, если записи нет. присваивать статус по умолчанию. Это сильно сократит размер таблицы с полутора миллионов.
BasePelleta, для чего нужно число после названия статуса?
Судя по всему, это время действия статуса.