postgresql группировка по дням
Группировка данных по временным интервалам
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Группировка по временным интервалам
Подскажите сделать группировку по некоторым временным интервалам какого нибудь параметра из таблицы.
Группировка данных по временным интервалам
Всем привет. Встала такая задача, что нужно некоторые эмпирические данные привязанные ко времени.
Привязка данных по дням к недельным интервалам
Ребята, всем привет:) Есть исходная форма отчета, где каждая операция по продаже привязана к коду.
Решение
не очень разбирался в тонкостях вашего запроса, по-моему здесь все очевидно.
extract ‘day’ в generate_series дает вам 4 дня для одинакового времени и 3 дня для чуть меньшего диапазона.
Добавлено через 1 минуту
вообще вы лучше более точно опишите Вашу задачу, будет легче переписать ваш запрос
Добавлено через 18 минут
спасибо grgdvo
Добавил интервал 1 микросекунду к началу периода,
но теперь вопрос как переадть параметр pPeriod
SQL Error [22023]: ОШИБКА: единицы interval «pperiod» не распознаны
только case можно использовать?
Не понял вопрос про case.
Алгоритм группировки данных для графика по интервалам времени
Строю график на MC, имею постоянный поток значении привязанных к времени. Типа 1.2 2016 06 12.
Группировка данных
Здравствуйте. Подскажите пожалуйста, каким образом можно вывести данные из такой структуры без.
Группировка данных
Всем привет! Не могу сообразить как мне сгруппировать данные или нормально вывести в таблицу В.
Группировка данных
Рассчитайте данные для таблицы, содержащей сведения о сумме операций по каждому счету. Вопрос в.
Группировать результаты запросов по месяцам и годам в postgresql
У меня есть следующая таблица базы данных на сервере Postgres:
Я хотел бы создать запрос, который дает SUM столбца Sales и группирует результаты по месяцам и годам следующим образом:
Есть ли простой способ сделать это?
5 ответов
По просьбе Раду я объясню этот запрос:
to_char(date,’Mon’) as mon, : преобразует атрибут «date» в заданный формат короткой формы месяца.
extract(year from date) as yyyy : функция «extract» Postgresql используется для извлечения года YYYY из атрибута «date».
sum(«Sales») as «Sales» : Функция SUM() объединяет все значения «Sales» и предоставляет псевдоним с учетом регистра, при этом чувствительность к регистру поддерживается с использованием двойных кавычек.
group by 1,2 : Функция GROUP BY должна содержать все столбцы из списка SELECT, которые не являются частью агрегата (ака, все столбцы не входят в функции SUM/AVG/MIN/MAX и т.д.). Это говорит о том, что SUM() следует применять для каждой уникальной комбинации столбцов, которые в этом случае являются столбцами месяца и года. Часть «1,2» является сокращением вместо использования псевдонимов столбцов, хотя, вероятно, лучше всего использовать полные выражения «to_char (. )» и «extract (. )» для удобочитаемости.
Здесь правильный способ сделать это, date_trunc:
Это плохая практика, но вам может быть прощено, если вы используете
в очень простом запросе.
Вы также можете использовать
если вы не хотите выбирать дату.
to_char фактически позволяет вам вытащить Год и месяц одним махом!
или в случае примера пользователя выше:
bma ответ велик! Я использовал его с ActiveRecords, вот он, если кому-то это нужно в Rails:
Postgress имеет несколько советов для временных меток в postgress:
временная метка с часовым поясом. Смещение временной зоны уже включено в метку времени.
В некоторых случаях ваша база данных не использует часовой пояс, но вам по-прежнему необходимо группировать записи по локальному часовому поясу и летнему времени (например, https://www.timeanddate.com/time/zone/romania/bucharest)
Чтобы добавить часовой пояс, вы можете использовать этот пример и заменить смещение часового пояса на ваше.
Чтобы добавить смещение Летнего времени +1 к DST, вам нужно проверить, попадает ли ваша временная метка в летнее летнее время. Поскольку эти интервалы меняются с 1 или 2 днями, я буду использовать аппроксимацию, которая не влияет на записи конца месяца, поэтому в этом случае я могу игнорировать каждый год точный интервал.
Если требуется более точный запрос, вам нужно добавить условия для создания большего числа случаев. Но, грубо говоря, это будет отлично работать в расщеплении данных в месяц в отношении часового пояса и SummerTime, когда вы найдете временную метку без часовой пояс в своей базе данных:
Запрос на выборку данных с группировкой по суткам
Прошу подсказать в написании запроса к базе с выводом данных по суткам
Имеется база с данными
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Запрос на выборку с группировкой бд Парковки
Доброго времени суток! Подскажите, пожалуйста у самого мозг не дотягивает. Есть две таблицы со.
Не могу составить запрос с группировкой данных
Здравствуйте. Никак не могу сообразить, как составить запрос, делающий выборку из таблицы (см. в.
Запрос к среднему по месяцу, суткам и по часам
В общем задача вообще хитрая и вот даж не знаю выполнимая али как. хочу получить данные с постгрес.
Такой вариант подойдет?
Нет, вы видимо не уловили мою мысль. Да ваш вариант работает для вывода любого указанного периода времени.
Но для моей выборки он не приемлем. BETWEEN ‘2017-01-01 09:00:00’ AND ‘2018-01-03 09:10:00’ делает то же самое.
Добавлено через 7 минут
Моя цель: вывести показания счетчика на каждые сутки в 9:00
Тем более вся куча записей не нужна, лишь те что нужно
1) у вас по-моему скрины перепутаны. Первым идет уже результат вашего запроса, а вторым идут исходные данные.
2) советую пока оставить в покое LEFT JOIN по пропущенным данным. Их вы уже в конце добавите, когда получите посчитанные данные из общей выборки. LEFT JOIN дорогая операция, делать ее для «сырых» данных накладно.
3) чтобы перейти на 9 часов, нужно эти 9 часов отнять от исходного timestamp, потом снова прибавите. то есть мы как бы сутки сдвигаем на 9 часов.
Функция DATEPART стр. 2
MySQL
В MySQL для извлечения каждой составляющей даты имеется соответствующая функция. Так, например, можно получить минуты времени отправления рейсов, которые вылетают в 1-ом часу дня (база данных «Аэропорт»):
Дополнительно с помощью функции EXTRACT можно получить составные компоненты даты/времени, например, год и месяц. Решим такую задачу.
Посчитать количество окрасок по месяцам с учетом года (база данных «Окраска»).
|
Здесь уместно будет отметить довольно вольную трактовку группировки в MySQL, при которой в списке столбцов предложения SELECT могут присутствовать столбцы с детализированными данными, отсутствующими в предложении GROUP BY. Очевидно, что агрегаты здесь подразумеваются, т.к., в противном случае, отсутствует однозначная интерпретация операции. Предполагаю, что здесь неявно используются функция MIN или MAX, но я даже не буду это специально выяснять, т.к. предпочитаю в подобных случаях следовать стандарту.
Функций типа Year, Month и т.д. в PostgreSQL, насколько мне известно, нет. Однако есть функция EXTRACT, и второе решение первой задачи, которое мы написали для MySQL, будет работать и под этой СУБД:
Имеется также функция, аналогичная DATEPART в MSSQL. Различия в синтаксисе, надеюсь, станут очевидны из примера решения той же задачи с использованием этой функции:
Тем не менее, мы можем реализовать идею составной компоненты при помощи функции форматирования даты TO_CHAR :
Результат будет аналогичен результату решения 3 за отсутствием первых двух столбцов, которые, разумеется, можно добавить в вывод, включив их одновременно в предложение GROUP BY, как это сделано в решении 4.
PostgreSQL. Группировка по временному интервалу
Сап, Лор! Есть поток данных с таймштампом:
Нужно этот поток сгруппировать, таким образом, что бы в каждой группы образовались рекорды с разницей во времени не более X. Т.е. на выходе получить что то типа такого:
а сейчас как вычисляется group_field?
Можно считать что всё уже пришло и хранится в базе? Если нет, то поток приходит всегда отсортированный по таймстампу?
В противном случае задача не имеет однозначного решения. Например, у тебя три точки с интервалом в 40 секунд. Их можно двумя способами (а то и тремя) разбить на группы.
немного анально конечно ), ябы лучше триггером заполнял это
Не можно, а нужно. В том то и дело, что поток не шотсортирован. Т. е. в общем случае, каждая запись содержит время, более позднее чем предыдущая, но существует несколько частных случаев когда эта закономерность нарушается. Причем эти частные случаи (как оказалось) весьма часты, к сожалению. В любом случае, группировать необходимо данные из таблицы.
А как разрешать коллизии? Очевидно же что набор ID-шек будет цикличным. Или я не так понял?
Например, у тебя три точки с интервалом в 40 секунд. Их можно двумя способами (а то и тремя) разбить на группы.
Ааа, т.е. группа заканчивается, когда наступает перерыв длиннее чем X?
Ну тогда мне кажется, это не стоит делать средствами SQL. Это нужно делать путём создания курсора, идущего по записям по порядку, и сравнивать следующее с предыдущим. Я не знаю postgres, но там есть возможность писать на языках программирования хранимые процедуры. Вот её и придётся использовать. В Firebird или MS SQL я бы именно хранимками бы воспользовался, если это нужно в оффлайне.
Если нужно в онлайне, то зависит от того, сколько клиентов могут одновременно писать. Если клиент один, то можно завести таблицу из одной записи с двумя полями: время последней записи и id группы этой последней записи. По сути это глобальная переменная в базе.
Вставка записи производится хранимкой, которая использует это время и обновляет его при каждой вставке, чтобы понять, пора ли начать новую группу.
Ну это сложная задачка. Тогда в любом случае id-ом группы я бы сделал тамстамп первого сообщения в группе. В остальном надо подумать. Надо ли, чтобы база в рилтайме принимала данные от клиентов или они могут повисеть некоторое время, пока база наведёт порядок с группами? Кстати, насчёт по модулю я неправильно сказал, не по модулю, а целое(число секунд с начала эпохи/X).
Ну индекс-то по таймстампу хотя бы ты можешь создать?
Тогда в любом случае id-ом группы я бы сделал тамстамп первого сообщения в группе.
Ну индекс-то по таймстампу хотя бы ты можешь создать?
Не суть важно что будет в поле, по которому надо группировать. Главное по этому что-то сгруппировать, и получить массив рекордов. А дальше кеширование в какую нибудь noSQL и работа с хешем.
это знакомая блин ситуация, в моем случае, правда «более старые» данные прийти не могут, просто GPS time vs internal RTC. и когда последние убегают вперед, получается дельтаТЭ отрицательной при синке времени девайсом.
Догадывался, что надо копать в сторону row_number.
не ровнумбер, скорее window functions нужен lag чтобы считать дельту и sum для start_of_group, это «паттерн» такой: отмечаешь начала групп, потом сум по ним для сквозной нумерации.
Нет, эти группы должны формироваться динамически, и должны отображать актуальность лишь на момент запроса.
ну по идее норм, попробовал на реальных данных
Как раз потому, что может прийти более раннее сообщение и группы могут внезапно склеиться, возникает простой факт: стабильность кода группы ни для какой записи не гарантирована. А раз так, время первой записи вполне подходит в качестве ключа группы. Что бы ты не взял в качестве кода группы, лучше не станет. Например, если ты будешь нумеровать группы по порядку, слияние двух групп в начале истории приведёт к перенумерации всех групп. А если ты будешь идентифицировать их временами первой записи, перенумеруется только более поздняя из слившихся групп.
Впервые вижу over, но почему у тебя тут order by id в группировке, если данные могут прийти не в порядке возрастания времени? Я так понял, автору темы нужен порядок по времени?
За рабочий запрос спасибо.
слияние двух групп в начале истории приведёт к перенумерации всех групп.
Ну нет, при слиянии групп, по сути, берется одна из групп (с наибольшим числом рекордов), в нее добавляются рекорды из меньшей группы, меньшая группа дропается.
Это я просто думаю про план запроса.
В данный момент на таблице 2 индекса: time и уникальный time + field1 + field2.
Postgres, а вообще построение индекса может замедлить работу БД, и его надо периодически перестраивать для балансировки.
Ну я выполняю VACUUM ANALYZE периодически xD.
Я так понял, автору темы нужен порядок по времени?
Да, это так, но поменять ордер уж я смогу. Вопрос изначально был даже больше в теоретическом плане, т.к. я вообще не представлял какой подход применить, сейчас вроде немного проясняется ситуация.
Если тебя устроит решение с группировкой по каким-то временным единицам (по секундам, по минутам, по часам, дням, неделям, месяцам или годам), тогда можешь использовать функцию date_trunc.
Ну нет, при слиянии групп, по сути, берется одна из групп (с наибольшим числом рекордов), в нее добавляются рекорды из меньшей группы, меньшая группа дропается.
Но дело твоё. Думаю, я больше ничем не могу быть здесь полезен.
please define «делишь на треки» не совсем понятно.
в моей ситуации (нагрузка не очень высокая, как по числу устройств, так и числу читателей) я сделал максимально просто. точки хранятся в огромной плоской таблице, пишутся туда максимально упрощенным демоном, практически без предварительного процессинга.
но у меня, в нормальной ситуации, время всегда растет в порядке вставки, те записи у которых это не так, говорят о проблеме.
читаю из базы я либо данные за последние ххх секунд для множества устройств. либо по устройству за интервал времени [s, f), по 1+ устройств.
потом полученный жирный датасет в Java пакуется в нужное представление, и отдается уже далее json или в отчеты. тут главное не выжрать всю память.
постпроцессинг инфы для треков не делал, тк все итак работает на текущих объемах довольно долго.