Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.12.151.153] |
|
Данный раздел предназначается для обсуждения вопросов использования баз данных, за исключением составления запросов на SQL. Для этого выделен специальный раздел. Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ. |
Страницы: (4) [1] 2 3 ... Последняя » все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Добрый вечер.
Суть проблемы - если таблица с полем read (записывается кол-во просмотров). Т. к. это поле только увеличивается со временем. необходимо сортировать по разнице за неделю. Т. е. каждую неделю поле read бэкапится в поле read2. Сортировка по полю получится такая ORDER by (read-read2). Но возникает проблема - после очередного бэкапа - сортировка не очевидна, т. к. поля read и read2 равны. Как решить проблему? На текущий момент тупо добавил поле read3 (read - текущее, read2 - неделю назад, read3 - 2 недели назад). Сортируется так ORDER By (read2-read3), т. е. по разнице за пред неделю. Но как сделать адекватную сортировку? |
Сообщ.
#2
,
|
|
|
Потом 4е поле, потом 5 и так далее. Есть подозрение что не с того конца задача решается. Я б подошел отсюда:
Бухучёт наше всё. В данном случае устройство таблички проводок дата, время, страничка откуда, страничка куда Соответственно количество посещений за любой период - по данной табличке с группировкой по иду "куда" И фильтром по периоду |
Сообщ.
#3
,
|
|
|
Цитата n0wheremany @ возникает проблема - после очередного бэкапа - сортировка не очевидна, т. к. поля read и read2 равны. Что за бред? бэкап никак не влияет на данные! А если при "бэкапе" данные изменяются - это ни хрена не бэкап. |
Сообщ.
#4
,
|
|
|
Цитата n0wheremany @ Суть проблемы - если таблица с полем read (записывается кол-во просмотров). Т. к. это поле только увеличивается со временем. необходимо сортировать по разнице за неделю. Т. е. каждую неделю поле read бэкапится в поле read2. Сортировка по полю получится такая ORDER by (read-read2). Но возникает проблема - после очередного бэкапа - сортировка не очевидна, т. к. поля read и read2 равны. Как решить проблему? Решается простым запросом. В котором все записи группируются по неделям (из записанной даты извлекается номер недели), в группе же сортируются по дате, в группе берется последний элемент, первый элемент, высчитывается разница просмотров. В результате запроса получается что-то типа "Номер недели", "Количество просмотров за неделю". ЗЫ: Никакие бэкапы для решения данной задачи не нужны. Бэкапы решают вопросы безопасности данных, либо сброс данных в архив (в бэкап) для предотвращения нежелательного роста БД. |
Сообщ.
#5
,
|
|
|
JoeUser и?
структура по первому посту Table(URL, read, read2) при новом просмотре происходит update table set read = read+1 where URL = ... И раз в неделю update table set read2 = read, read = 0 И все. Какие суммы? какие группировки? |
Сообщ.
#6
,
|
|
|
Цитата Павел Калугин @ И все. Какие суммы? какие группировки? Нахрена дополнительные поля (я имею ввиду read2)? Я так понимаю, речь идет о банальном логе просмотров. Лог и лог, чего тут городить что-то дополнительно, если задача расчета тривиальнейша? |
Сообщ.
#7
,
|
|
|
Дурацкая (извините за грубость) структура с учётом поставленной задачи.
Для фиксации просмотров должна существовать таблица истории обращений (УРЛ-дата-количество). Если прошло обращение к УРЛу - плюсим единицу за текущую дату, если запись отсутствует - создаём её с количеством = 1. Для сортировки по описанному принципу - просто суммируем обращения за последние 7 дней. Общее количество получаем, суммируя без учёта даты (ну или для повышения оперативной производительности храним переопределённое поле общего количества обращений). |
Сообщ.
#8
,
|
|
|
Цитата Akina @ Дурацкая (извините за грубость) структура с учётом поставленной задачи. Вот и я о том же Добавлено Цитата Akina @ Если прошло обращение к УРЛу - плюсим единицу за текущую дату, если запись отсутствует - создаём её с количеством = 1. Хотя я так бы не делал. Вдруг взбредет потом построить график обращений к URL за сутки? Мне кажется, лучше просто добавлять. А уже вопрос роста БД-лога решать иными способами (бэкап "оперативных" данных в "архивные" + чистка "оперативных" данных). |
Сообщ.
#9
,
|
|
|
хм... Поясню по сабжу.
Есть только 1 таблица post с полями id,read. Я не хочу создавать отдельную таблицу для сохранения просмотров - это глупо и лишняя нагрузка. Т. к. поле read и даёт информацию по просмотрам (аналогично SELECТ count(*)). Сейчас нужно получить изменение этого поля и отсортировать по нему. Т. к. в таблицу post добавляются строки не часто, сортировать по полю read смысла нет - получится что старые строки всегда будут в верху. Добавил поле read2 что бы сохранять туда данные раз в неделю запросом update table set read2 = read и сортирую строки ORDER BY (read-read2). Но после сохранения (бэкапа) read-read2 равны и сортировка соответственно не адекватна. Решил вопрос пока таким образом - добавил поле read3. Обновление такое update table set read3 = read2, read2 = readи сортировка соответственно ORDER BY (read2-read3). Т. е. сортировка по изменению предыдущей недели. Но хотелось бы по текущей каким то образом - есть ли варианты без создания доп таблицы |
Сообщ.
#10
,
|
|
|
n0wheremany, ты написал что ты сделал. Но не указал исходные данные и каков желаемый результат. Одну и туже задачу можно решать разными путями. Соберись с мыслями и напиши вменяемую постановку задачи.
|
Сообщ.
#11
,
|
|
|
JoeUser Сори если не понятно )
Исходные данные таблица post с полями id,read. Обновление поля read происходит update post set read=read+1 про просмотре поста. Задача - отсортировать таблицу по изменению за неделю поля read без создания дополнительных таблиц с минимальной нагрузкой |
Сообщ.
#12
,
|
|
|
Цитата JoeUser @ Хотя я так бы не делал. Вдруг взбредет потом построить график обращений к URL за сутки? Вот именно предложенная мной схема и позволит такой график построить. Цитата n0wheremany @ Я не хочу создавать отдельную таблицу для сохранения просмотров - это глупо и лишняя нагрузка. Ну вместо того, чтобы решить задачу оптимальным образом, который, кстати, соответствует модели бизнес-процесса, Вы его решаете кривым костылём... ну чё, хозяин - барин. |
Сообщ.
#13
,
|
|
|
Цитата Akina @ Для фиксации просмотров должна существовать таблица истории обращений (УРЛ-дата-количество). Если прошло обращение к УРЛу - плюсим единицу за текущую дату, если запись отсутствует - создаём её с количеством = 1. Даже не так. Каждое обращение отдельной записью. Количество обращений в день - count по этой таблице за день Для ускорения обработки можно делать разные "срезы" вида кол-во обращений за день/неделю/месяц, "кол-во обращений с группировкой по источнику" и т.д. и т.п. Расчет срезов проводить в "наименее активное время". Соответственно для оперативной отчетности остается к последнему срезу добавить данные за текущий. В общем задача тривиальна и многократно в разных вариациях решена в разных учетных системах. По сути отчет "покажи дебетовый оборот по расчетным счетам за период ... в порядке ..." Добавлено Цитата n0wheremany @ Я не хочу создавать отдельную таблицу для сохранения просмотров - это глупо и лишняя нагрузка. это единственное разумное решение. Тупо заливать лог просмотров. Один быстрый инсерт Цитата n0wheremany @ Это не бекап.. посмотрите внимательно на это Но после сохранения (бэкапа) read-read2 равны и сортировка соответственно не адекватна. Цитата Павел Калугин @ update table set read2 = read, read = 0 и все, вот ваш костыль.. Вам надо не копировать а переносить данные. Но все равно это кривизна полная так считать Цитата n0wheremany @ Решил вопрос пока таким образом - добавил поле read3. Завтра будете read4 добавлять и так далее? Пока в допустимую "ширину" таблицы не упретесь? Цитата n0wheremany, 1460978442 @ Но хотелось бы по текущей каким то образом - есть ли варианты без создания доп таблицы Это не доп. таблица. Это исходные данные об обращениях к сайту, на базе которых можно построить любую отчетность с любой сортировкой. Например я встречал, когда народ на очень нагруженных сайтах изучает поминутно статистику, с привязками к часовым поясам пользователя и т.д. Цитата Akina @ Вот именно предложенная мной схема и позволит такой график построить. а почасовой график? А в разрезе географии? Цитата n0wheremany @ Задача - отсортировать таблицу по изменению за неделю поля read без создания дополнительных таблиц с минимальной нагрузкой минимальной нагрузкой на что? На сервер или на руки разработчика? Или на усилия пользователя отчетности? Или на дальнейшее масштабирование отчетности? |
Сообщ.
#14
,
|
|
|
Цитата Akina @ Вот именно предложенная мной схема и позволит такой график построить. Не. Если ты будешь Цитата Akina @ Если прошло обращение к УРЛу - плюсим единицу за текущую дату ... то "почасовые" данные у тебя теряются. |
Сообщ.
#15
,
|
|
|
Цитата n0wheremany @ Исходные данные таблица post с полями id,read. Обновление поля read происходит update post set read=read+1 про просмотре поста. Да нет же!!! Исходные данные - это не то, что ты сделал. Нет еще этой таблицы. Есть, к примеру: сервер, который отдает какую информацию по URL. Нужно не вводить поля read1, read2, ... read78 (это тоже твоя костыльная реализация). А нужно, к примеру: мочь рассчитать рейтинг запросов в разрезе URL за период времени. |