|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Есть таблица идентификаторов товаров: Код: sql 1. 2.
Содержание: Код: plaintext
Есть три таблицы, где есть расход по этим товарам: Код: sql 1. 2. 3.
Содержание: Код: plaintext
[USAGE2] Код: sql 1. 2.
Содержание: Код: plaintext 1.
[USAGE3] Код: sql 1. 2.
Содержание: Код: plaintext 1. 2.
Нужно одним запросом посчитать суммы по всем трем таблицам: Код: sql 1. 2. 3. 4. 5. 6.
Получаю это: Код: plaintext 1.
Ну и без группировки это выглядит так: Код: plaintext 1. 2. 3. 4. 5. 6.
Какой JOIN мне нужно использовать чтобы данные не дублировались? Сейчас делаю три отдельных запроса, но это очень некрасиво. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 08:25 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Rom1, тебе нужен не JOIN, а UNION из SELECT'ов сумм, если хочешь суммы построчно. Если хочешь суммы по столбцам, то нужен один SELECT, у которого значение каждого поля суммы представлено результатом суммирующего SELECT'а. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 09:06 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Rom1 Код: plaintext 1. 2.
rdb_dev тебе нужен не JOIN, а UNION из SELECT'ов сумм Надеюсь, понимаешь разницу между UNION и UNION ALL? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 11:06 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
wadman, ALL, это опция UNION. Возьмёт Reference Manual и разберётся. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 12:56 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
не разберётся. это тестовая задача. дорога' ложка к обеду. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 12:59 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Мимопроходящий, значит в этот раз повезёт тестирующему, а не тестируемому. Знавал я одного ребятёнка, который после ВУЗа с дипломом программиста пытался устроиться в Корус вообще без знаний, что такое СУБД и чем её едят. Корусу повезло, ребятёнку нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 13:07 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
rdb_dev Rom1, тебе нужен не JOIN, а UNION. Но ведь UNION создаёт новую временную таблицу (в MySQL, в Firebrd не знаю), это же даст отрицательный результат производительности? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 16:26 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Мимопроходящий не разберётся. это тестовая задача. дорога' ложка к обеду. Молодой человек, с чего вы взяли что я студент? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 16:27 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Rom1, не создаёт он никаких временных таблиц, уж в ФБ точно. UNION в отличие от UNION ALL требует сортировку для удаления дубликатов и вот тут есть потеря производительности. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 16:34 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Симонов Денис UNION в отличие от UNION ALL требует сортировку для удаления дубликатов и вот тут есть потеря производительности. Еще хуже, когда плюс потеря данных в некоторых случаях, как выше. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 16:35 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Хорошо, если я вынесу (вынес) все эти "три" запроса в процедуру (ранее выполнял их на клиенте), а процедура выдаёт агрегированный результат, насколько это может отличаться по производительности по сравнению с UNION? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 16:38 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Rom1, а чем вот такой вариант не подходит? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 16:53 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
KreatorXXI Rom1, а чем вот такой вариант не подходит? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Да, сам уже дошел до такого: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Результат: Код: plaintext 1. 2. 3. 4. 5. 6.
Честно говоря, если встречу такой запрос в коде, решу что его писал наркоман. "from GOODS" у меня не просто таблица, а ресурсоёмкий запрос по выборке товаров, по которым надо сделать такую агрегацию, поэтому сделать его хочу один раз за запрос. А вот трижды делать его - полный провал. Как и в вашем примере, если гудсов тысяча, то запросов будет три тысячи, если я правильно понимаю, а это тоже фейл. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 17:03 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Rom1с чего вы взяли что я студент? Слишком кривая схема данных, слишком странное требование "одним запросом". Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 17:10 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Rom1, причём тут GOODS1, если в запросе KreatorXXI он вычитывается ровно один раз. Это к его результатам добавляются результаты 3-х подзапросов ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 17:11 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Rom1, можно и таким образом сделать: Код: sql 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 17:14 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Слишком кривая схема данных, слишком странное требование "одним запросом". Ничего кривого не вижу. Требование простое "отдать всю работу с клиента на сервер", в идеале одним запросом. Симонов Денис Rom1, причём тут GOODS1, если в запросе KreatorXXI он вычитывается ровно один раз. Это к его результатам добавляются результаты 3-х подзапросов Я не знаю как СУБД устроена внутри, возможно будет основной запрос товаров, после идентификаторы сериализуются и передаются в те три запроса, в результате имеем четыре запроса. Может быть и так, я не знаю, пусть эксперты подтвердят. Лично я смотрю "в лоб" и вижу в этом примере, что на каждый товар по три запроса, 1000 товаром, 3000 запросов. Но может это и не так, я же написал - "насколько понимаю". wadman Rom1, можно и таким образом сделать: [/src] KreatorXXI уже привел подобный пример ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 17:25 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Rom1Ничего кривого не вижу. Три разные таблицы с общим назначением "расход" и совершенно одинаковой структурой. Так БД обычно не делают. Rom1Требование простое "отдать всю работу с клиента на сервер", в идеале одним запросом. Вот этот "идеал" - как раз студенческий уровень. Три простых отдельных запроса часто быстрее одного хитроподвыподвертнутого. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 17:47 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
У дубликатов значений полей в результирующем наборе видны 2 причины: 1. Таковы данные, как мы видим в топике (похоже, ошибочные, но весьма показательные) Код: plaintext 1. 2. 3.
2. Размножение в результате слияний по JOIN OUTER . Задача, позволю себе домыслить за автора, состоит в удалении дубликатов по второй причине при сохранении таковых по причине 1. Любой инструмент, действующий на результирующий набор, будь то UNION ALL или SUM( U3.AMOUNT distinct ) или еще подобный, удалит дубликаты независимо от причины, и, значит, не решит задачу. Посему пока что видны 2 направления в сторону решения: а) Принять как постулат, что исходные данные не могут повторяться, и применить к выходному набору вышеуказанные инструменты. б) Писать отдельные запросы (хотя бы в виде подзапросов) по каждому полю. Сугубо ИМХО. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 18:16 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
shalamyansky У дубликатов значений полей в результирующем наборе видны 2 причины: 1. Таковы данные, как мы видим в топике (похоже, ошибочные, но весьма показательные) Код: plaintext 1. 2. 3.
... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 18:28 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Значит, вам подходит решение (а). Добавьте слово distinct в агрегатную функцию, и довольно будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 18:34 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Rom1Но чтобы не быть голословным при написании вопроса, создал все базы таблицы Чтобы не быть голословным это надо было делать в https://dbfiddle.uk/?rdbms=firebird_3.0 а сюда постить линк на уже готовые данные. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 18:34 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Rom1 Dimitry Sibiryakov Слишком кривая схема данных, слишком странное требование "одним запросом". Ничего кривого не вижу. Требование простое "отдать всю работу с клиента на сервер", в идеале одним запросом. Симонов Денис Rom1, причём тут GOODS1, если в запросе KreatorXXI он вычитывается ровно один раз. Это к его результатам добавляются результаты 3-х подзапросов Я не знаю как СУБД устроена внутри, возможно будет основной запрос товаров, после идентификаторы сериализуются и передаются в те три запроса, в результате имеем четыре запроса. Может быть и так, я не знаю, пусть эксперты подтвердят. Лично я смотрю "в лоб" и вижу в этом примере, что на каждый товар по три запроса, 1000 товаром, 3000 запросов. Но может это и не так, я же написал - "насколько понимаю". и чего это тебя смущает, проверь и посмотри планы и время выполнения и пользы больше и времени потраченного немного А уж если время выполнения не устроит то и приходи, помогут тут ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 18:36 |
|
Прошу помощи с JOIN
|
|||
---|---|---|---|
#18+
Rom1 Да, сам уже дошел до такого: Где же дошёл? Union all скорее всего будет невыгодным в Вашем случае. Если как у меня не получается, то есть "Select from select", есть CTE. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2021, 09:53 |
|
|
start [/forum/topic.php?fid=40&fpage=3&tid=1559898]: |
0ms |
get settings: |
12ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
50ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
76ms |
get tp. blocked users: |
2ms |
others: | 239ms |
total: | 416ms |
0 / 0 |