На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! информация о разделе
user posted imageДанный раздел предназначается для обсуждения вопросов использования баз данных, за исключением составления запросов на SQL. Для этого выделен специальный раздел. Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ.

Модераторы: Chow, Bas, MIF
Страницы: (4) [1] 2 3 ... Последняя » все  ( Перейти к последнему сообщению )  
> Проблема сортировки по разнице изменения числа
    Добрый вечер.

    Суть проблемы - если таблица с полем read (записывается кол-во просмотров). Т. к. это поле только увеличивается со временем. необходимо сортировать по разнице за неделю. Т. е. каждую неделю поле read бэкапится в поле read2. Сортировка по полю получится такая ORDER by (read-read2). Но возникает проблема - после очередного бэкапа - сортировка не очевидна, т. к. поля read и read2 равны.
    Как решить проблему?

    На текущий момент тупо добавил поле read3 (read - текущее, read2 - неделю назад, read3 - 2 недели назад). Сортируется так ORDER By (read2-read3), т. е. по разнице за пред неделю. Но как сделать адекватную сортировку?
      Потом 4е поле, потом 5 и так далее. Есть подозрение что не с того конца задача решается. Я б подошел отсюда:
      Бухучёт наше всё. В данном случае устройство таблички проводок ;) дата, время, страничка откуда, страничка куда
      Соответственно количество посещений за любой период - по данной табличке с группировкой по иду "куда"
      И фильтром по периоду ;)
      Сообщение отредактировано: Павел Калугин -
        Цитата n0wheremany @
        возникает проблема - после очередного бэкапа - сортировка не очевидна, т. к. поля read и read2 равны.

        Что за бред? бэкап никак не влияет на данные! А если при "бэкапе" данные изменяются - это ни хрена не бэкап.
          Цитата n0wheremany @
          Суть проблемы - если таблица с полем read (записывается кол-во просмотров). Т. к. это поле только увеличивается со временем. необходимо сортировать по разнице за неделю. Т. е. каждую неделю поле read бэкапится в поле read2. Сортировка по полю получится такая ORDER by (read-read2). Но возникает проблема - после очередного бэкапа - сортировка не очевидна, т. к. поля read и read2 равны.
          Как решить проблему?


          Решается простым запросом. В котором все записи группируются по неделям (из записанной даты извлекается номер недели), в группе же сортируются по дате, в группе берется последний элемент, первый элемент, высчитывается разница просмотров. В результате запроса получается что-то типа "Номер недели", "Количество просмотров за неделю".

          ЗЫ: Никакие бэкапы для решения данной задачи не нужны. Бэкапы решают вопросы безопасности данных, либо сброс данных в архив (в бэкап) для предотвращения нежелательного роста БД.
            JoeUser и?
            структура по первому посту
            Table(URL, read, read2)
            при новом просмотре происходит
            update table set read = read+1 where URL = ...
            И раз в неделю
            update table set read2 = read, read = 0
            И все. Какие суммы? какие группировки?
              Цитата Павел Калугин @
              И все. Какие суммы? какие группировки?

              Нахрена дополнительные поля (я имею ввиду read2)? Я так понимаю, речь идет о банальном логе просмотров. Лог и лог, чего тут городить что-то дополнительно, если задача расчета тривиальнейша?
                Дурацкая (извините за грубость) структура с учётом поставленной задачи.
                Для фиксации просмотров должна существовать таблица истории обращений (УРЛ-дата-количество). Если прошло обращение к УРЛу - плюсим единицу за текущую дату, если запись отсутствует - создаём её с количеством = 1. Для сортировки по описанному принципу - просто суммируем обращения за последние 7 дней. Общее количество получаем, суммируя без учёта даты (ну или для повышения оперативной производительности храним переопределённое поле общего количества обращений).
                  Цитата Akina @
                  Дурацкая (извините за грубость) структура с учётом поставленной задачи.

                  Вот и я о том же

                  Добавлено
                  Цитата Akina @
                  Если прошло обращение к УРЛу - плюсим единицу за текущую дату, если запись отсутствует - создаём её с количеством = 1.

                  Хотя я так бы не делал. Вдруг взбредет потом построить график обращений к URL за сутки? Мне кажется, лучше просто добавлять. А уже вопрос роста БД-лога решать иными способами (бэкап "оперативных" данных в "архивные" + чистка "оперативных" данных).
                    хм... Поясню по сабжу.

                    Есть только 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). Т. е. сортировка по изменению предыдущей недели.

                    Но хотелось бы по текущей каким то образом - есть ли варианты без создания доп таблицы
                      n0wheremany, ты написал что ты сделал. Но не указал исходные данные и каков желаемый результат. Одну и туже задачу можно решать разными путями. Соберись с мыслями и напиши вменяемую постановку задачи.
                        JoeUser Сори если не понятно )

                        Исходные данные таблица post с полями id,read. Обновление поля read происходит update post set read=read+1 про просмотре поста.

                        Задача - отсортировать таблицу по изменению за неделю поля read без создания дополнительных таблиц с минимальной нагрузкой
                          Цитата JoeUser @
                          Хотя я так бы не делал. Вдруг взбредет потом построить график обращений к URL за сутки?

                          Вот именно предложенная мной схема и позволит такой график построить.

                          Цитата n0wheremany @
                          Я не хочу создавать отдельную таблицу для сохранения просмотров - это глупо и лишняя нагрузка.

                          Ну вместо того, чтобы решить задачу оптимальным образом, который, кстати, соответствует модели бизнес-процесса, Вы его решаете кривым костылём... ну чё, хозяин - барин.
                            Цитата Akina @
                            Для фиксации просмотров должна существовать таблица истории обращений (УРЛ-дата-количество). Если прошло обращение к УРЛу - плюсим единицу за текущую дату, если запись отсутствует - создаём её с количеством = 1.

                            Даже не так. Каждое обращение отдельной записью. Количество обращений в день - count по этой таблице за день
                            Для ускорения обработки можно делать разные "срезы" вида кол-во обращений за день/неделю/месяц, "кол-во обращений с группировкой по источнику" и т.д. и т.п.
                            Расчет срезов проводить в "наименее активное время".
                            Соответственно для оперативной отчетности остается к последнему срезу добавить данные за текущий.
                            В общем задача тривиальна и многократно в разных вариациях решена в разных учетных системах. По сути отчет "покажи дебетовый оборот по расчетным счетам за период ... в порядке ..."

                            Добавлено
                            Цитата n0wheremany @
                            Я не хочу создавать отдельную таблицу для сохранения просмотров - это глупо и лишняя нагрузка.

                            это единственное разумное решение. Тупо заливать лог просмотров. Один быстрый инсерт
                            Цитата n0wheremany @
                            Но после сохранения (бэкапа) read-read2 равны и сортировка соответственно не адекватна.
                            Это не бекап.. посмотрите внимательно на это
                            Цитата Павел Калугин @
                            update table set read2 = read, read = 0

                            и все, вот ваш костыль.. Вам надо не копировать а переносить данные. ;) Но все равно это кривизна полная так считать
                            Цитата n0wheremany @
                            Решил вопрос пока таким образом - добавил поле read3.

                            Завтра будете read4 добавлять и так далее? Пока в допустимую "ширину" таблицы не упретесь?
                            Цитата n0wheremany,
                            1460978442 @
                            Но хотелось бы по текущей каким то образом - есть ли варианты без создания доп таблицы

                            Это не доп. таблица. Это исходные данные об обращениях к сайту, на базе которых можно построить любую отчетность с любой сортировкой. ;)
                            Например я встречал, когда народ на очень нагруженных сайтах изучает поминутно статистику, с привязками к часовым поясам пользователя и т.д.

                            Цитата Akina @
                            Вот именно предложенная мной схема и позволит такой график построить.

                            а почасовой график? А в разрезе географии?

                            Цитата n0wheremany @
                            Задача - отсортировать таблицу по изменению за неделю поля read без создания дополнительных таблиц с минимальной нагрузкой

                            минимальной нагрузкой на что? На сервер или на руки разработчика? Или на усилия пользователя отчетности? Или на дальнейшее масштабирование отчетности?
                              Цитата Akina @
                              Вот именно предложенная мной схема и позволит такой график построить.

                              Не. Если ты будешь
                              Цитата Akina @
                              Если прошло обращение к УРЛу - плюсим единицу за текущую дату

                              ... то "почасовые" данные у тебя теряются.
                                Цитата n0wheremany @
                                Исходные данные таблица post с полями id,read. Обновление поля read происходит update post set read=read+1 про просмотре поста.

                                Да нет же!!! Исходные данные - это не то, что ты сделал. Нет еще этой таблицы.
                                Есть, к примеру: сервер, который отдает какую информацию по URL.
                                Нужно не вводить поля read1, read2, ... read78 (это тоже твоя костыльная реализация).
                                А нужно, к примеру: мочь рассчитать рейтинг запросов в разрезе URL за период времени.
                                Сообщение отредактировано: JoeUser -
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0773 ]   [ 16 queries used ]   [ Generated: 28.03.24, 09:13 GMT ]