3 / 3 / 3
Регистрация: 01.06.2016
Сообщений: 307
|
|||||||||||||||||||||
1 | |||||||||||||||||||||
Объединение запросов07.03.2017, 11:38. Показов 20123. Ответов 14
Метки нет (Все метки)
Здравствуйте.
Имеются несколько запросов к БД:
Офис 1 Офис 2 Офис 3 Офис 4
1 3 5 4
Подскажите пожалуйста, как всё это объединить в один запрос, чтобы в итоге получилась одна таблица с названиями офисов и показателями по ним из примеров выше? Пробовал использовать UNION ALL, но выдало ошибку.
0
|
07.03.2017, 11:38 | |
Ответы с готовыми решениями:
14
Объединение 2 запросов или 1 запрос Объединение запросов Объединение запросов объединение запросов |
1251 / 967 / 382
Регистрация: 02.09.2012
Сообщений: 2,976
|
|
07.03.2017, 14:53 | 2 |
Чтобы связать все эти запросы в одно целое, нужно понимать как между собой связаны все упомянутые таблицы. Нужна модель данных. Того, что написано в разрозненных запросах, недостаточно.
0
|
3 / 3 / 3
Регистрация: 01.06.2016
Сообщений: 307
|
|
13.03.2017, 13:57 [ТС] | 3 |
grgdvo, из PostgreSQL это можно как-то извлечь?
0
|
3 / 3 / 3
Регистрация: 01.06.2016
Сообщений: 307
|
|
13.03.2017, 15:40 [ТС] | 5 |
grgdvo, вот, надеюсь, это то, что нужно.
0
|
1251 / 967 / 382
Регистрация: 02.09.2012
Сообщений: 2,976
|
||||||
14.03.2017, 15:44 | 6 | |||||
Ну не очень диаграмма. Начните вот с этой версии запроса.
0
|
3 / 3 / 3
Регистрация: 01.06.2016
Сообщений: 307
|
||||||||||||||||
14.03.2017, 17:30 [ТС] | 7 | |||||||||||||||
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
|
1251 / 967 / 382
Регистрация: 02.09.2012
Сообщений: 2,976
|
||||||
15.03.2017, 05:11 | 8 | |||||
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 [ТС] | 9 |
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
|
1251 / 967 / 382
Регистрация: 02.09.2012
Сообщений: 2,976
|
|
15.03.2017, 10:13 | 10 |
вот как раз для onpriem, que и stat и не хватает описания связующих полей. какие поля в этих таблицах отвечают за связь с электронной очередью???
а с ОШИБКОЙ это я сглупил, копипастил запрос с предыдущего поста и не исправил. Конечно должна быть сортировка по sp_struc.naz, т.е. ORDER BY sp_struc.naz
1
|
3 / 3 / 3
Регистрация: 01.06.2016
Сообщений: 307
|
||||||
15.03.2017, 11:19 [ТС] | 11 | |||||
grgdvo, да, так получилось. Это мы узнали сколько где на приёме людей. Таким же образом остальные запросы можно присобачить?
sp_que.id = onpriem.idq = que.idq = stat.idq - это все номера электронных очередей, они и связаны между собой. Добавлено через 54 минуты Попробовал вот так:
0
|
1251 / 967 / 382
Регистрация: 02.09.2012
Сообщений: 2,976
|
||||||
15.03.2017, 15:52 | 12 | |||||
Сообщение было отмечено Prtoy как решение
Решение
1
|
3 / 3 / 3
Регистрация: 01.06.2016
Сообщений: 307
|
||||||
15.03.2017, 16:03 [ТС] | 13 | |||||
grgdvo, спасибо большое. Только чуть-чуть подправил, в 12 строке WHERE sp_que.id = stat.idq и надо было за выбранную дату, с определённым параметром (rez = 1), т.е. 12 строка получилась:
0
|
1251 / 967 / 382
Регистрация: 02.09.2012
Сообщений: 2,976
|
|
15.03.2017, 16:14 | 14 |
COUNT(*) вы просто считаете записи, которые выбрали из таблицы
SUM - суммирует числовые значения. Идея такая. Сначала в подзапросе q1 подсчитываем все количества записей из зависимых таблиц. Если ничего не выбираем из зависимых таблиц, то COUNT(*) насчитает 0. Далее уже аккумулированные данные связываем с таблицей имен и поскольку очередей для каждого офиса потенциально может быть больше одной, то все посчитанные количества надо просуммировать. В итоге получается не самый удачный план запроса, который будет долго выбирать на больших объемах данных. Интуитивно мне кажется можно как-то совместить SUM и OUTER JOIN для всех пяти таблиц в один запрос, чтобы получился оптимальный план запроса, но я уже пас на сегодня работать. Хотите, исследуйте производительность самостоятельно.
0
|
3 / 3 / 3
Регистрация: 01.06.2016
Сообщений: 307
|
|
15.03.2017, 16:31 [ТС] | 15 |
Спасибо. Срабатывает быстро, таблицы с очередями вряд ли вырастут настолько, чтобы нужно было данный запрос оптимизировать... Сам вряд ли справлюсь, нужно более углублённо изучать SQL, и скорее всего, начинать с нуля
Спасибо ещё раз за помощь.
0
|
15.03.2017, 16:31 | |
15.03.2017, 16:31 | |
Помогаю со студенческими работами здесь
15
Объединение запросов Объединение запросов Объединение 2х запросов в 1 Объединение запросов Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |