|
3 / 3 / 3
Регистрация: 01.06.2016
Сообщений: 307
|
|||||||||||||||||||||
Объединение запросов07.03.2017, 11:38. Показов 21212. Ответов 14
Метки нет (Все метки)
Здравствуйте.
Имеются несколько запросов к БД:
Офис 1 Офис 2 Офис 3 Офис 4
1 3 5 4
Подскажите пожалуйста, как всё это объединить в один запрос, чтобы в итоге получилась одна таблица с названиями офисов и показателями по ним из примеров выше? Пробовал использовать UNION ALL, но выдало ошибку.
0
|
|||||||||||||||||||||
| 07.03.2017, 11:38 | |
|
Ответы с готовыми решениями:
14
Объединение 2 запросов или 1 запрос Объединение запросов Объединение запросов |
|
1267 / 980 / 385
Регистрация: 02.09.2012
Сообщений: 3,027
|
|
| 07.03.2017, 14:53 | |
|
Чтобы связать все эти запросы в одно целое, нужно понимать как между собой связаны все упомянутые таблицы. Нужна модель данных. Того, что написано в разрозненных запросах, недостаточно.
0
|
|
|
3 / 3 / 3
Регистрация: 01.06.2016
Сообщений: 307
|
|
| 13.03.2017, 13:57 [ТС] | |
|
grgdvo, из PostgreSQL это можно как-то извлечь?
0
|
|
|
3 / 3 / 3
Регистрация: 01.06.2016
Сообщений: 307
|
|
| 13.03.2017, 15:40 [ТС] | |
|
grgdvo, вот, надеюсь, это то, что нужно.
0
|
|
|
1267 / 980 / 385
Регистрация: 02.09.2012
Сообщений: 3,027
|
||||||
| 14.03.2017, 15:44 | ||||||
|
Ну не очень диаграмма. Начните вот с этой версии запроса.
0
|
||||||
|
3 / 3 / 3
Регистрация: 01.06.2016
Сообщений: 307
|
||||||||||||||||
| 14.03.2017, 17:30 [ТС] | ||||||||||||||||
|
grgdvo,
Не получилось. ОШИБКА: таблица "sp_struct" отсутствует в предложении FROM LINE 18: sp_struct.naz Добавлено через 15 минут По этой ошибке разобрался,
"ОШИБКА: столбец "sp_que.ids" должен фигурировать в предложении GROUP BY или использоваться в агрегатной функции" Добавил в GROUP BY столбец sp_que.ids (GROUP BY sp_struc.naz, sp_que.ids) - после этого запрос сработал, но выдал какие-то нереальные данные, плюс одинаковые во всех столбцах. Плюс, исчез один из офисов. Если поменять местами столбцы (GROUP BY sp_que.ids, sp_struc.naz) - то выходят все офисы, но данные также нереальные и одинаковые. Добавлено через 17 минут Ещё пытался с джойнами сделать, хотя бы первые два запроса, примерно так:
ОШИБКА: в элементе предложения FROM неверная ссылка на таблицу "sp_que" HINT: Таблица "sp_que" присутствует в запросе, но сослаться на неё из этой части запроса нельзя.
0
|
||||||||||||||||
|
1267 / 980 / 385
Регистрация: 02.09.2012
Сообщений: 3,027
|
||||||
| 15.03.2017, 05:11 | ||||||
|
JOIN конструкция должна быть "цельной". В подвыражении ON вы не можете использовать другие таблицы кроме тех, которые перечислены слева и справа от JOIN. Запятая не в счет, это уже другой вид соединения других таблиц.
Вся проблема в соединениях связана с тем, что модель связей таблиц четко не прописана. У вас в принципе queue.onpriem висячая таблица, непонятно как она с кем связана. Также по смыслу непонятно, что таблицы обозначают и какая смысловая связь между ними. Если главная сущность sp_struc - офис (больница), в больнице существует одна (может больше) электронная очередь - queue.sp_que, в настоящий момент на приеме есть пациенты из такой-то очереди (может быть нескольких очередей) - queue.onpriem, то вероятно можно запрос так построить
1
|
||||||
|
3 / 3 / 3
Регистрация: 01.06.2016
Сообщений: 307
|
|
| 15.03.2017, 08:14 [ТС] | |
|
grgdvo, Так тоже не получилось, ОШИБКА: столбец "sp_que.ids" должен фигурировать в предложении GROUP BY или использоваться в агрегатной функции.
Да, не имея самой базы под рукой, сложно понять... Попробую словами объяснить. isp.sp_struc - это таблица с оргиназациями (оттуда нам нужны только их названия - sp_struc.naz) queue.sp_que - это таблица с электронными очередями (названий организаций тут нет, зато есть ид организаций, к которым привязываются очереди - ids). queue.onpriem - таблица со значениям о тех, кто на приёме queue.que - таблица с текущей очередью queue.stat - статистика (сколько кого было в очередях, на приёме, и т.д.) onpriem.idq, que.idq - номера очередей, они равны sp_que.id Можно конечно сделать модель всей базы данных, там очень много всяких таблиц и зависимостей, но теоретически этих двух должно хватать.
0
|
|
|
1267 / 980 / 385
Регистрация: 02.09.2012
Сообщений: 3,027
|
|
| 15.03.2017, 10:13 | |
|
вот как раз для onpriem, que и stat и не хватает описания связующих полей. какие поля в этих таблицах отвечают за связь с электронной очередью???
а с ОШИБКОЙ это я сглупил, копипастил запрос с предыдущего поста и не исправил. Конечно должна быть сортировка по sp_struc.naz, т.е. ORDER BY sp_struc.naz
1
|
|
|
3 / 3 / 3
Регистрация: 01.06.2016
Сообщений: 307
|
||||||
| 15.03.2017, 11:19 [ТС] | ||||||
|
grgdvo, да, так получилось. Это мы узнали сколько где на приёме людей. Таким же образом остальные запросы можно присобачить?
sp_que.id = onpriem.idq = que.idq = stat.idq - это все номера электронных очередей, они и связаны между собой. Добавлено через 54 минуты Попробовал вот так:
0
|
||||||
|
1267 / 980 / 385
Регистрация: 02.09.2012
Сообщений: 3,027
|
||||||
| 15.03.2017, 15:52 | ||||||
Сообщение было отмечено Prtoy как решение
Решение
1
|
||||||
|
3 / 3 / 3
Регистрация: 01.06.2016
Сообщений: 307
|
||||||
| 15.03.2017, 16:03 [ТС] | ||||||
|
grgdvo, спасибо большое. Только чуть-чуть подправил, в 12 строке WHERE sp_que.id = stat.idq и надо было за выбранную дату, с определённым параметром (rez = 1), т.е. 12 строка получилась:
0
|
||||||
|
1267 / 980 / 385
Регистрация: 02.09.2012
Сообщений: 3,027
|
|
| 15.03.2017, 16:14 | |
|
COUNT(*) вы просто считаете записи, которые выбрали из таблицы
SUM - суммирует числовые значения. Идея такая. Сначала в подзапросе q1 подсчитываем все количества записей из зависимых таблиц. Если ничего не выбираем из зависимых таблиц, то COUNT(*) насчитает 0. Далее уже аккумулированные данные связываем с таблицей имен и поскольку очередей для каждого офиса потенциально может быть больше одной, то все посчитанные количества надо просуммировать. В итоге получается не самый удачный план запроса, который будет долго выбирать на больших объемах данных. Интуитивно мне кажется можно как-то совместить SUM и OUTER JOIN для всех пяти таблиц в один запрос, чтобы получился оптимальный план запроса, но я уже пас на сегодня работать. Хотите, исследуйте производительность самостоятельно.
0
|
|
|
3 / 3 / 3
Регистрация: 01.06.2016
Сообщений: 307
|
|
| 15.03.2017, 16:31 [ТС] | |
|
Спасибо. Срабатывает быстро, таблицы с очередями вряд ли вырастут настолько, чтобы нужно было данный запрос оптимизировать... Сам вряд ли справлюсь, нужно более углублённо изучать SQL, и скорее всего, начинать с нуля
![]() Спасибо ещё раз за помощь.
0
|
|
| 15.03.2017, 16:31 | |
|
Помогаю со студенческими работами здесь
15
объединение запросов
Объединение запросов Объединение 2х запросов в 1 Объединение запросов Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
Настройки VS Code
Loafer 13.04.2026
{
"cmake. configureOnOpen": false,
"diffEditor. ignoreTrimWhitespace": true,
"editor. guides. bracketPairs": "active",
"extensions. ignoreRecommendations": true,
. . .
|
Оптимизация кода на разграничение прав доступа к элементам формы
Maks 13.04.2026
Алгоритм из решения ниже реализован на нетиповом документе, разработанного в конфигурации КА2.
Задачи, как таковой, поставлено не было, проделанное ниже исключительно моя инициатива.
Было так:. . .
|
Контроль заполнения и очистка дат в зависимости от значения перечислений
Maks 12.04.2026
Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2.
Задача: реализовать контроль корректности заполнения дат назначения. . .
|
Архитектура слоя интернета для сервера-слоя.
Hrethgir 11.04.2026
В продолжение https:/ / www. cyberforum. ru/ blogs/ 223907/ 10860. html
Знаешь что я подумал? Раз мы все источники пишем в голове ветки, то ничего не мешает добавить в голову такой источник, который сам. . .
|
|
Подстановка значения реквизита справочника в табличную часть документа
Maks 10.04.2026
Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2.
Задача: при выборе сотрудника (справочник Сотрудники) в ТЧ документа. . .
|
Очистка реквизитов документа при копировании
Maks 09.04.2026
Алгоритм из решения ниже применим как для типовых, так и для нетиповых документов на самых различных конфигурациях.
Задача: при копировании документа очищать определенные реквизиты и табличную. . .
|
модель ЗдравоСохранения 8. Подготовка к разному выполнению заданий
anaschu 08.04.2026
https:/ / github. com/ shumilovas/ med2. git
main ветка * содержимое блока дэлэй из старой модели теперь внутри зайца новой модели
8ATzM_2aurI
|
Блокировка документа от изменений, если он открыт у другого пользователя
Maks 08.04.2026
Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в конфигурации КА2.
Задача: запретить редактирование документа, если он открыт у другого пользователя.
/ / . . .
|