Akina

SELECT Запись_на_прием.ID_Записи, Водитель.ФИО Водитель, Врач.ФИО Врач
FROM Запись_на_прием
JOIN Пользователь AS Водитель ON Водитель.ID_Пользователя = Запись_на_прием.ID_Водитель 
JOIN Пользователь AS Врач ON Врач.ID_Пользователя = Запись_на_прием.ID_Врач
;

MS SQL online test

Если меняете маску на 255.255.254.0, то ни о каком WAN на Zyxel 1 не должно идти речи.
Zyxel 1 остаётся в качестве свитча (порт WAN свободный).
DHCP собрать в одном месте
или взять управляемые свитчи, умеющие DHCP snooping, тогда можно оставить два независимых DHCP на двух ZyXEL'ях.

Так как из второй таблицы данные не выбираются - попробуйте (NOT EXISTS):

SELECT 
  task.id, 
  task.dc, 
  task.provider, 
  task.type, 
  task.url, 
  task.cost, 
  task.cost_bot, 
  task.last_start_msec, 
  task.url_id, 
  task.remains, 
  task.cat 
FROM 
  Task task 
WHERE 
  task.status = 'active' 
  AND task.type = 'follow_profile' 
  AND task.provider = 'insta' 
  AND task.cat = 3 
  AND NOT EXISTS(
	SELECT 1 FROM  TaskFlow flow 
	WHERE 
		flow.url_id = task.url_id 
		AND flow.executor_acc_id = $acc 
  );

У таблиц нет никакого порядка строк, если вы не указываете его явно в запросе.

select * from resume order by id asc;

SUM(), JOIN, GROUP BY

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...