Akina

GROUP BY и COUNT

SELECT post_id, count(post_id) as cnt FROM MyTable GROUP BY post_id

Это элементарный вопрос, на который ответит любой школьник, изучающий информатику

давайте я погуглю за Вас
https://winitpro.ru/index.php/2018/08/03/dobavit-v....

Элементарный запрос на суммирование с группировкой:

SELECT id, SUM(price) sum_price
FROM tbl
GROUP BY id
ORDER BY sum_price DESC;

SQL SUM GROUP BY

До чего изобретателен может быть человек, не понимающий что он делает!
Ключевое слово: кортеж.
await cur.execute(sql, (id))
(id) - это то же самое, что id.
А вот (id,) - это уже кортеж из одного элемента.
execute() как раз и ожидает вторым параметром кортеж, или иную коллекцию, где один элемент - это одно подставляемое значение.

Этот метод необходим для удаления скобок, которые ставит pymysql при обычном fetchone

"Скобки", как ты выразился - это потому что fetchone() возвращает кортеж, по одному элементу на значение в строке (ну или None если очередной строки нет). Т.е. для каждого пункта между SELECT и FROM будет один элемент в кортеже, в том же порядке. Ты запрашиваешь только teleid, поэтому получаешь кортеж из одного элемента.
Получить этот элемент можно, обратившись по индексу 0.

row = await cur.fetchone()
if row is not None: #есть хоть одна строка?
    teleid = row[0]
    # дальше делаешь что хочешь с teleid
else: # нет такой строки
    print('Беда')

Перед тем как писать ботов, освой азы языка, а? Структуры данных в частности.

Интерполировать. Как именно - зависит от того, как используются автомобили.
Если предположить, что пробег каждый день одинаковый, то берём общий пробег за интервал и делим на кличество дней в интервале. Затем либо сохраняем полученный средний пробег для каждого дня интервала, либо вычисляем пробег на конец месяца и сохраняем помесячно.
Если, например, весь пробег только в будни, то, соответственно, вычисляем количество рабочих дней в интервале и делим на него. При раскидывании по дням, опять же, записываем нулевой пробег в выходные и средний в будни.

Представьте обратную ситуацию - хост и его шлюз НЕ находятся в пределах одной сети. Тогда, очевидно, чтобы отправить пакет шлюзу, требуется какой-то узел в сети, маршрутизирующий пакеты за её пределы. Хоп, вы получили новый шлюз.

Подскажите, в чем может быть проблема? Спасибо!!!

Подсказываю: Файлы хранятся в файловой системе. Хранить файлы в бд это палка о двух концах, оба из которых засунуты в ж...
1) Файловые системы работают с файлами гораздо лучше текстовых хранилищ.
2) Для отдачи файлов из файлов не нужно выполнять запросы к бд, десериализацию, декодирование из жсон, а затем из базе64, и гнать как ответ от пыха к серверу. Еще и гонять туда-сюда МНОГО данных, бд такое не любит. Просто отдаешь путь к файлу и его сервер напрямую читает.
3) Проще настраивать кэширование на стороне клиента, когда файл отдается не через скрипт, а "как файл"
4) Хранение в базе64 - это +30% примерно к весу изображения
И еще дохрена проблем...

Единственный более-менее аргумент за хранение в базе картинок - отдавать их по запросу только авторизированным пользователям. И то, тут правильнее хранить путь до них, сами картинки держать опять же в фс, выше документ рута, и отдавать их через readfile();

В остальном хранить файлы в бд - решение такое же здравое, как хранить деньги в акциях Российских компаний...

Что значит стопорится? зачем гадать, расставь по больше вывода в свои логи отладочной информации (когда принял запрос, обработал, отправил транзакцию, когда получил ответ от базы и т.п.) с таймингами и смотри что и где происходит в проблемный момент

Что за пиз...ц с сериализацией картинок в base64 потом это все в json, а в базе хранить php-щным serialize?

http post прекрасно справляется с отправкой файлов, там своя сериализация, никто не мешает миксить в запросе get и post данные

Не храните картинки в базе данных, никак, ни блобом ни сериализацией, кто придумал этот маразм, в каком бредовом туториале это прочитали и каждый второй это реализует?

Файлы храни в файлах на диске, а в базу записывай путь или имя файла (либо сам файл по идентификатору называй), раз в сто лет на обслуживании базы сравнивай наличие файлов на диске и записей в базе и удаляй висяки (образуются если во время обработки произошла ошибка, например скрипт умер, файл записали а транзакция в базе откатилась)

p.s. в php во всех репозитариях есть красивый сериализатор igbinary, если что он в каком то смысле даже быстрее старого serialize и точно компактнее, его потихоньку в стандарт пропихивают, например можно использовать его для хранения сессий

Если известно количество устройств (и соответственно количество колонок в итоговой таблице) - можно. Пример для 4 устройств:

CREATE TABLE data(
  device INT NOT NULL,
  date DATETIME NOT NULL,
  metric NUMERIC(10,2) NOT NULL
);

INSERT INTO data VALUES (1, '2022-01-01 00:00:00', 2.34),
(2, '2022-01-01 00:00:00', 1.23),
(3, '2022-01-01 00:00:00', 3.82), 
(4, '2022-01-01 00:00:00', 0.45),
(1, '2022-01-01 01:00:00', 2.00),
(2, '2022-01-01 01:00:00', 1.82),
(3, '2022-01-01 01:00:00', 3.09);

SELECT date, SUM(d1), SUM(d2), SUM(d3), SUM(d4) FROM (
SELECT date,
CASE WHEN device=1 THEN metric ELSE NULL END AS d1,
CASE WHEN device=2 THEN metric ELSE NULL END AS d2,
CASE WHEN device=3 THEN metric ELSE NULL END AS d3,
CASE WHEN device=4 THEN metric ELSE NULL END AS d4
FROM data
) nested
GROUP BY date;

https://sqlize.online/sql/mysql80/68e677a2fc577e6c...

А вот промер для пяти ;)

select 
	_date,
	sum(case when _ustr = 1 then _metr else 0 end) _ustr_1,
	sum(case when _ustr = 2 then _metr else 0 end) _ustr_3,
	sum(case when _ustr = 3 then _metr else 0 end) _ustr_3,
	sum(case when _ustr = 4 then _metr else 0 end) _ustr_4,
	sum(case when _ustr = 5 then _metr else 0 end) _ustr_5
from tbl
group by _date;

SQL online

Просто размышление.
Логика подсказывает, что такой подход применяется, когда нужно не просто обойти все дерево как-нибудь, а обойти в порядке сортировки дерева (или в обратном порядке).

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

На каком именно этапе проверять родителя в таком случае зависит от того как сортируются потомки относительно родителя в данном конкретном случае. Т.е. в бинарном дереве левый потомок меньше родителя, а правый больше - это правило и создает упорядоченность при обходе. Если узлов больше 2, то нужно определить аналогичное правило упорядоченности для потомков относительно родителя. в соответствии с этим правилом и совершать обход.

В поле set возможно только 64 значения, так как по факту это битовая маска. У тебя в запросе их 87. Придется переходить на подчиненную таблицу или JSON поле

А что вы пытаетесь тут сделать? Вот конкретно этот подзапрос (SELECT id FROM test1) он для чего? Вы выбираете все записи из таблицы test1, что, как бы, очень подозрительно. А если там будет миллион записей?

У вас в триггере есть переменные NEW и OLD, указывающие на обновленную запись в таблице test1 - вот и используйте их, чтобы определить какие записи в таблице test2 вам нужно обновить.

Подумать. Потому что такая проблема указывает что база данных денормализована, соответственно это может быть ошибка проектирования. Если это не ошибка - подумать еще раз. Если все равно так и должно быть - читать про триггеры, либо закладывать логику синхронизации таблиц в логику приложения.

Идея дурацкая, если честно, но сделать можно:

create sequence shared_sequence;
create table production_data(id bigint default nextval('shared_sequence'), value text);
create table demo_data(id bigint default nextval('shared_sequence'), value text);