- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Дорого времени!
У меня на сайте интегрирована система рейтинга, т.е. голосовать можно сразу по десяткам вопросов, методом "за" и "против", так вот, каждый отданный голос создает новую строку в таблице SQL, и теперь меня беспокоит вопрос разумности такой организации. Уже сейчас за неделю 300 новых строк, что будет дальше, и следует ли что то изменить, или это нормально?
Зависит от того, как часто вы обращаетесь к накопленным данным, и как часто их изменяете.
300 новых строк за неделю — небольшой прирост (субъективно).
;9178789']Зависит от того, как часто вы обращаетесь к накопленным данным, и как часто их изменяете.
300 новых строк за неделю — небольшой прирост (субъективно).
Я не знаток, поэтому смею предположить, что обращение происходит каждый раз при подсчете рейтинга, который в свою очередь происходит во время запроса серверу на генерацию страницы рейтинга. Получается что всегда, или нет?
Должно быть две таблицы.
В первой хранятся просто числа рейтинг
Во второй хранятся уже данные юзера, с которыми сравниваются, мол не голосовал ли он.
Так же можно переделать, чтобы были не новые строки, а всё в одной. Зачем их плодить то? Пусть в столбец IP записываются и всё.
SQL это язык запросов, а вот база MySQL или любая подобная достаточно резиновая.
Скажем так: миллион строк в таблице, даже если их этого миллиона надо 10 раз в секунду выбирать десяток строк, это не так много записей, конечно, если грамотно созданы индексы и продуманы (оптимизированы) запросы к базе.
То есть всё зависит не от числа строк а от параметров этих самых строк и SQL запросов, которые оперируют этими строками, с лёгкостью можно оперировать миллионами строк, но можно и на сотне строк "повесить" сервер наглухо.
Если опишите задачу или покажете структуру таблиц и запросы, то можно будет говорить по существу, что делать, как улучшить.
предмет голосования|количество ЗА|количество ПРОТИВ
эти ж данные чаще всего запрашиваются, таблица получится маленькой и легкой. менять только цифры.
+ отдельную таблицу: лог голосования (кто за что проголосова), чекать при получении голоса от пользователя.
предмет голосования|количество ЗА|количество ПРОТИВ
эти ж данные чаще всего запрашиваются, таблица получится маленькой и легкой. менять только цифры.
+ отдельную таблицу: лог голосования (кто за что проголосова), чекать при получении голоса от пользователя.
я бы применил, но я не спец. в целом удовлетворен, понял что париться не стоит. Всем спасибо!)
В принципе не правильно так делать. База хоть и резиновая, но через год обрабатывать тысячи строк для простого результата голосования - это лишняя нагрузка, а ля вордпресс получится.
LEOnidUKG правильный вариант подсказал, этого надо придерживаться.
Должно быть две таблицы.
В первой хранятся просто числа рейтинг
Во второй хранятся уже данные юзера, с которыми сравниваются, мол не голосовал ли он.
С точки зрения организация и хранения данных оно может быть и правильно, но такая организация замедлит работу - выборки усложнятся: вместо считывания данных с одной таблицы, будут считываться с двух более сложным запросом.
Dmitry.Z, все правильно сказал.
LEOnidUKG правильный вариант подсказал, этого надо придерживаться.
не уверен в этом. Объем сохраняемых даных это уменьшит, но никак не быстродействие.
Reise добавил 11.07.2011 в 00:26
понял что париться не стоит
не стоит, правильно поняли. У вас имхо лучший вариант. Сейчас с винтами проблем нет, проблема с вычислительными ресурсами.
У меня таблицы mySQL весят десятки гигов, ничо, полёт наманый :)
Или вы про другой Structured Query Language говорите?
А ведь было...