"Подбить результат"

← →
User1 (2008-05-15 09:52) [0]

Есть ли в SQL возможность подбить результат последней строчкой или как то так. Например:

SELECT Column1, SUM(Column2) AS Column2 FROM Table1 GROUP BY Column1

А необходимо развернуть список из чего слаживается сумма, и "подбить результат"

Чтото типа:

SELECT Column1, Column2 FROM Table1 ???????????? SUM(Column2)

?

← →
Ega23 © (2008-05-15 09:59) [1]

union all

← →
Игорь Шевченко © (2008-05-15 10:22) [2]

База какая ?

"Кто последний зарплату получать? Моя фамилия Итого"

← →
User1 (2008-05-15 10:53) [3]

> Игорь Шевченко © (15.05.08 10:22) [2]

MS SQL Server 2005

← →
Style © (2008-05-15 11:03) [4]

group by WITH ROLLUP?

← →
MsGuns © (2008-05-15 12:11) [5]

Правильный ответ в [1] только all необязательно
Только вот неясно для чего. Подбитый итог, как, впрочем и сам нд, в конце концов нужен не серверу, а клиенту. Поэтому этот самый клиент вполне в состоянии дать два запроса - один для выборки, второй - на итог. Для достоверности оба завернуть в одну транзакцию

← →
Style © (2008-05-15 12:14) [6]

> Поэтому этот самый клиент вполне в состоянии дать два запроса
> - один для выборки, второй - на итог.

если использовать ADO можно воспользоваться и оператором COMPUTE BY, тогда
запрос вернет 2 рекордсета, в первом выборка, во втором сумма

← →
Игорь Шевченко © (2008-05-15 12:18) [7]

> Правильный ответ в [1] только all необязательно

обязательно

← →
MsGuns © (2008-05-15 12:22) [8]

>Игорь Шевченко © (15.05.08 12:18) [7]
>обязательно

???

← →
Игорь Шевченко © (2008-05-15 12:23) [9]

MsGuns © (15.05.08 12:22) [8]

union без all удаляет дублирующиеся записи из выходного набора

← →
Style © (2008-05-15 12:27) [10]

более того UNION ALL на раз быстрее , т.к. не сортирует данные при объединении )

← →
Ega23 © (2008-05-15 12:29) [11]

all обязательно.
Вопрос в другом: как автор будет этот "довесок" отличать от реального НД? Т.е. он должен добиться того, чтобы в "довеске" ВСЕГДА была СТРОГО одна запись. Даже если основной НД - пустой.
Либо вводить служебное поле в выборку с "идентификатором НД".

ИМХО - всё это жуткий изврат. Просуммировать результат и на клиенте можно, на AfterOpen.

← →
Style © (2008-05-15 12:34) [12]

> ИМХО - всё это жуткий изврат. Просуммировать результат и
> на клиенте можно, на AfterOpen.

а мое ИМХО, использовать compute by на SQL Server, гораздо эффективнее, ну не нужен просто второй запрос. (главное чтобы клиент поддерживал, чтение нескольких recordset). Другое дело такой код далек от стандарта ANSI-SQL и просто не переносим на другие сервера отличные от Microsoft ) А надо ли вообще переносить и будет ли необходимость в рамках проекта - это уже вопрос аффтору )

← →
Умище (2008-05-15 13:59) [13]

пишешь 1 запрос на выборку нужных записей, 2-й запрос на суммирование. Оба подзапроса объединяешь оператором UNION (ALL не нужен).

← →
Style © (2008-05-15 14:19) [14]

> Умище (15.05.08 13:59) [13]
> UNION (ALL не нужен).

еще раз внимательно перечитываем ветку с самого начала!

← →
Sergey13 © (2008-05-15 14:20) [15]

> [13] Умище (15.05.08 13:59)
> ALL не нужен

Ну ты тогда обоснуй, почему не нужен.

← →
MsGuns © (2008-05-15 14:27) [16]

Итоговый запрос вынужден быть по формату идентичным основному, возвращающему строки. В неитоговые колонки итоговой записи (записей) можно положить некоторые константные значения, заведомо не совпадающие ни с одной из строк датасета. В этом случае они не будут выброшены из результирующего нд юнионом. Зачем тут All ?
Другое дело, как эти итоги всунуть непосредственно после последних строчек групп записей, к которым они относятся, если итожатся группы записей, а не весь нд.
В таких случаях, ИМХО, проще и удобнее всю эту байду делать на стороне сервера, в ХП например.

← →
Style © (2008-05-15 14:31) [17]

> Зачем тут All ?

еще раз:

использование оператора UNION совместно с ALL не
удаляет дублирующиеся записи (значения)

Чтобы удалить дублирующие серверу необходимо отсортировать данные
а это уже накладно, особенно для больших данных.

Соответственно использование UNION ALL - быстрее

← →
Style © (2008-05-15 14:32) [18]

> Другое дело, как эти итоги всунуть непосредственно после
> последних строчек групп записей, к которым они относятся,
> если итожатся группы записей, а не весь нд.

см. WITH ROLLUP и GROUPING

← →
Игорь Шевченко © (2008-05-15 14:36) [19]

MsGuns © (15.05.08 14:27) [16]

> Зачем тут All ?

Какой ты настырный

ora10> CREATE TABLE foo ( 2 amt NUMBER, 3 key CHAR(1) 4 ); Table created. ora10> INSERT INTO foo VALUES (1,"A"); 1 row created. ora10> INSERT INTO foo VALUES (2,"B"); 1 row created. ora10> INSERT INTO foo VALUES (1,"A"); 1 row created. ora10> INSERT INTO foo VALUES (1,"B"); 1 row created. ora10> SELECT amt, key FROM foo 2 UNION 3 SELECT sum(amt), key FROM foo GROUP BY key; AMT K ---------- - 1 A 1 B 2 A 2 B 3 B ora10> SELECT amt, key FROM foo 2 UNION ALL 3 SELECT sum(amt), key FROM foo GROUP BY key; AMT K ---------- - 1 A 2 B 1 A 1 B 2 A 3 B 6 rows selected. ora10> DROP TABLE foo; Table dropped. ora10>

← →
MsGuns © (2008-05-15 14:45) [20]

Мимо.
Во-первых, речь шла о выборке не столько НД, сколько о прикрутке к нему итогов, или я не въезжаю ?
Во-вторых, для выборки нужных строк основного датасета программист обязан позаботиться о том, чтобы строчки не дублировались, что легко сделать, добавив с список выводимых полей UID. Если его нет,- то проектировщика базы на бубуку (хотя, если он - ИШ, то в Урюпинск).

← →
Игорь Шевченко © (2008-05-15 14:46) [21]

MsGuns © (15.05.08 14:45) [20]

> Во-вторых, для выборки нужных строк основного датасета программист
> обязан позаботиться о том, чтобы строчки не дублировались

Сережа, ты прочитай пост номер [0], плз. Потом мы продолжим нашу увлекательную дискуссию.

← →
Style © (2008-05-15 14:50) [22]

> Если его нет,- то проектировщика базы на бубуку (хотя, если
> он - ИШ, то в Урюпинск).

Если нет дублирующих записей - это не означает что оператор UNION не будет проверять их наличие. А вот ALL - это гарантирует.

← →
MsGuns © (2008-05-15 14:56) [23]

Обращаю твое внимание на то, что сам запрос (без агрегатов) написан не просто неправильно, а бессмыслено, ибо из него совершенно не видно, данные о каких ОБЪЕКТАХ, извлекаются с сервера (не говоря уже об их "обитоживании"). Ясно, что это просто притмер, болванка. Но в реальности подобные кривости - сущая беда и вопят о необходимости высечь и высушить их авторов.
Хотя ФОРМАЛЬНО ты частично прав - для УКАЗАННОГО случая All нужен. Частично потому, что не всякий сервер вернет ВСЕ записи, если его специально об этом не попросить. Поэтому что с All, что без оного, такой сервер отработает одинаково

← →
MsGuns © (2008-05-15 14:58) [24]

>Style © (15.05.08 14:50) [22]
>Если нет дублирующих записей - это не означает что оператор UNION не будет >проверять их наличие. А вот ALL - это гарантирует.

Однако зависит от сервера, не так ли ?
Я не говорил, что ALL не нужен. Я говорил, что необязателен. Почувствуйте разницу.

← →
Игорь Шевченко © (2008-05-15 14:58) [25]

MsGuns © (15.05.08 14:56) [23]

> Обращаю твое внимание на то, что сам запрос (без агрегатов)
> написан не просто неправильно, а бессмыслено, ибо из него
> совершенно не видно, данные о каких ОБЪЕКТАХ, извлекаются
> с сервера

А и не надо знать.

> Частично потому, что не всякий сервер вернет ВСЕ записи,
> если его специально об этом не попросить.

С этого момента подробнее пожалуйста. Я по темноте своей считал, что если специально не ограничивать, что вернутся все записи :)
То есть, у меня вопрос - какой сервер вернет "не все записи, если его специально об этом не попросить" ?

← →
Sergey13 © (2008-05-15 15:01) [26]

> [23] MsGuns © (15.05.08 14:56)
> Поэтому что с All, что без оного, такой сервер отработает одинаково

То, что совпадает результат не говорит, что количество работы было одинаковым. Для результата (в данном случае) действительно фиолетово С ALL или без ALL, но вот по затратам сервера одинаковости не получится.

← →
Style © (2008-05-15 15:07) [27]

> Однако зависит от сервера, не так ли ?

Если задублировались записи в запросе - это не означает что индекс не уникальный, это может быть и не корректный JOIN. В любом случае UNION без ALL будет проверять их и сортировать на стороне сервера данные и запрос будет выполняться медленнее.

> Я не говорил, что ALL не нужен. Я говорил, что необязателен.
> Почувствуйте разницу.

Да необязателен!
Медленнее или Быстрее. Почувствуйте разницу.

← →
Игорь Шевченко © (2008-05-15 15:14) [28]

Sergey13 © (15.05.08 15:01) [26]

Дело не в количестве. Дело в полученных данных. При использовании UNION автор запроса обязан гарантировать, что все строки будут уникальны, если он не хочет, чтобы они удалились из результата. Можно делать это искусственно, как предлагает MsGuns, вводя некое уникальное поле, но я боюсь, что при выборке из источника, в котором уникальность гарантировано отсутствует (например соединение нескольких таблиц - первое, что пришло на ум), обеспечивать уникальность будет несколько затруднительно.
И все из-за того, что кто-то боится слово ALL написать.

>Игорь Шевченко © (15.05.08 14:58) [25]
>> Частично потому, что не всякий сервер вернет ВСЕ записи,
>> если его специально об этом не попросить.

>С этого момента подробнее пожалуйста. Я по темноте своей считал, что если специально >не ограничивать, что вернутся все записи :)
>То есть, у меня вопрос - какой сервер вернет "не все записи, если его специально об этом >не попросить" ?

Как пример - парадокс (QBE), если не сказать чеку "Plus", то записи "ужмутся". Вроде для SQL та же фигня, но не уверен.

>Style ©, 27Sergey13 ©

Кто о чем, а Василиса о папиросах. Мы обсуждаем оптимальностьвыборки на сервере или способ решения сабжа "чисто с клиента" ? Если первое, то тогда прочитайте [23] и подумайте об оптимальности бессмысленного запроса. Если способ решения, то каким боком такая критика утверждения о том, что All не является ОБЯЗАТЕЛЬНЫМ ?

> и подумайте об оптимальности бессмысленного запроса.

я говорю не про данный запрос. Я говорю про UNION в глобальном смысле, научить себя писать ALL даже в маленьких и бессмысленных запросах и потом не тратить лишнее время на оптимизацию своего кода. В этом смысле использование ALL - обязательно!

> или способ решения сабжа "чисто с клиента" ?

Тут вообще речь шла про решения сабжа на сервере. Так вот еще раз ИМХО для SQL-сервер лучше всего COMPUTE BY или ROLLUP

MsGuns © (15.05.08 15:17) [29]

> если не сказать чеку "Plus", то записи "ужмутся". Вроде
> для SQL та же фигня, но не уверен.

А где у SQL чек, которому надо сказать "Плюс" ?

> Кто о чем, а Василиса о папиросах. Мы обсуждаем оптимальностьвыборки
> на сервере или способ решения сабжа "чисто с клиента" ?
> Если первое, то тогда прочитайте [23] и подумайте об оптимальности
> бессмысленного запроса. Если способ решения, то каким боком
> такая критика утверждения о том, что All не является ОБЯЗАТЕЛЬНЫМ
> ?

Вот я специально не поленился и привел пример с таблицей, данными и запросами с Union и Union all.
В случае union возвращается 5 записей, в случае union all - 6

Ты до сих пор продолжаешь утверждать, что запрос неправильный ? :)

>Игорь Шевченко © (15.05.08 15:26) [31]
>А где у SQL чек, которому надо сказать "Плюс" ?

там написано QBE

>Вот я специально не поленился и привел пример с таблицей, данными и запросами с >Union и Union all.
>В случае union возвращается 5 записей, в случае union all - 6
>Ты до сих пор продолжаешь утверждать, что запрос неправильный ? :)

Твой "специальный" пример лишен практического смысла и демонстрирует лишь отличие оператора UNION c ALL и без. Для чего, собственно, и агрегаты нафиг не нужны (а сабж был о них непосредственно).
Игорь, я написал сотни запросов с ентим самым юнионом и ни разу (во всяком случае не помню) не использовал его с ALL. И все прекрасно живет и "не жужжит" (с).
Мне к Кетмарю за метлой ?

MsGuns © (15.05.08 15:36) [32]

Ну не знаю я QBE в Paradox. Посыпаю голову пеплом. К SQL он не имеет отношения.

> Твой "специальный" пример лишен практического смысла и демонстрирует
> лишь отличие оператора UNION c ALL и без. Для чего, собственно,
> и агрегаты нафиг не нужны (а сабж был о них непосредственно).
>

Во-первых, почему пример лишен практического смысла ?
Во-вторых, если ты внимательно прочитал [0], то там говорится о том, чтобы объединить агрегаты с детализацией (хочу видеть из чего собралась сумма)
Так вот, если в детализации будут повторяющиеся строки (надеюсь, ты им в этом не собираешься отказывать и не требуешь от них уникальности), то union их съест за милую душу.

>Игорь Шевченко © (15.05.08 15:40) [33]
>Ну не знаю я QBE в Paradox. Посыпаю голову пеплом. К SQL он не имеет отношения.

Вообще-то имеет. Открой борландовский доскотоп и убедись.

>Во-первых, почему пример лишен практического смысла ?

Потому что его там нет. Как нет никакого практического смысла в простом наборе комбинации цифр и букв.

>Во-вторых, если ты внимательно прочитал [0], то там говорится о том, чтобы объединить >агрегаты с детализацией (хочу видеть из чего собралась сумма)

Ага.

>Так вот, если в детализации будут повторяющиеся строки (надеюсь, ты им в этом не >собираешься отказывать и не требуешь от них уникальности), то union их съест за милую >душу.

Собираюсь отказывать. Требую. О чем достаточно прозрачно изъяснился в [23]
Съест. За милую душу. В этом случае All нужен. Где я утверждал обратное ?

Глупый спор на самом деле, нужны повторяющиеся записи, не нужны - дело личное каждого программиста. Я стараюсь писать запросы правильно, чтобы небыло ненужных повторяющихся записей. И мало встречал на практике такого чтобы они вдруг появлялись. А значит надо просто понимать что лишняя проверка дело - не желательное, поэтому я пишу UNION ALL. Получается что использовать просто UNION это как бы от неуверенности, в том что записи могут случайно задублироваться? А если речь идет о суммировании столбца, ну может у меня вообще ОДИН столбец с ценами товаров в запросе и я хочу в конце прописать итог с помощью UNION ALL - в этом случае ALL просто обязателен, т.к. значения-то (цены) могут повторятся :)

Серёг, да открой ты хелп, в конце-концов... :)

MsGuns © (15.05.08 15:48) [34]

> Вообще-то имеет. Открой борландовский доскотоп и убедись.

У меня его нету, рад бы открыть, да не могу.

> Собираюсь отказывать. Требую. О чем достаточно прозрачно
> изъяснился в [23]

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

Поэтому твой подход в данном случае не применим.

Тебе еще пример написать ? :)

> [28] Игорь Шевченко © (15.05.08 15:14)
> Дело не в количестве. Дело в полученных данных.

Я и писал про полученные данные.

Для запроса

SELECT Column1, SUM(Column2) AS Column2 FROM Table1 GROUP BY Column1 Union ALL SELECT "Итого", SUM(Column2) AS Column2 FROM Table1

И с ALL и без него результат будет одинаковый и по количеству и по составу данных (если конечно всесто "Итого" не написать значение единственного идентификатора имеющего суммируемые данные). Т.е. ALL вроде бы и необязательный, раз уникальность практически гарантируется. Но по затратам сервера этого не скажешь, и то, что "И все прекрасно живет и "не жужжит"" говорит лишь о достаточных железных ресурсах.

to Sergey13 © (15.05.08 16:53) [38]
как я поняла первая часть запроса должна бы выглядеть
SELECT Column1, Column2 FROM Table1 "то из чего складывается сумма"

> [39] ^-k2-^ © (15.05.08 16:57)

Ну тогда может быть. Я понял так как понял.
Сейчас пеерчитал вопрос - наверное ты права.

"Подбить результат" Найти похожие ветки