GROUP BY

← →
Climber © (2006-09-28 21:10) [0]

Проштудировал хэлп. Вопрос встал острее =) Сабжевая функция ведь выдаст записи с уникальным SS.

select ss,count(ss)
from base
group by ss
having count(ss)>10

А мне необходимы ВСЕ записи базы base, в которых присутствует ss, который в базе встречается > 10 раз.

При том, что в select нужно еще поля добавлять и, соответственно, добавлять их в GROUP BY, после чего кол-во выданных запросом записей еще резко сокращается.

Я чего-то не дочитал?

← →
Anatoly Podgoretsky © (2006-09-28 21:23) [1]

В таком случае какой GROUP BY

← →
Fay © (2006-09-28 23:31) [2]

with Q as (select ss from base group by ss having count(*) > 10) select B.* from base B, Q where B.ss = Q.ss

← →
evvcom © (2006-09-29 08:23) [3]

> [2] Fay © (28.09.06 23:31)

А with то здесь зачем? Даже для оракла. Есть возможность написать стандартный SQL, пиши, если нет или оптимальнее нестандарт, тогда уж и with, и прочие вкусности. Здесь же он не нужен.

← →
Fay © (2006-09-29 11:09) [4]

2 evvcom © (29.09.06 8:23) [3]
> Есть возможность написать стандартный SQL, пиши
Для СУБД афтара подходит только with

← →
evvcom © (2006-09-29 11:14) [5]

> [4] Fay © (29.09.06 11:09)
> Для СУБД афтара

Что-то у меня со зрением? Не вижу упоминания СУБД в [0]. Если есть with, то наверняка подойдет и
select B.* from base B inner join (select ss from base group by ss having count(*) > 10) Q on B.ss = Q.ss
Зачем здесь with?

← →
Desdechado © (2006-09-29 11:17) [6]

> Для СУБД афтара подходит только with
Это для какой?

← →
Fay © (2006-09-29 11:34) [7]

2 Desdechado
> Это для какой?
ХЗ

2 evvcom
> Не вижу упоминания СУБД в [0]
Я тоже не вижу.

Т.о. решение не противоречит постановке.

> возможность написать стандартный SQL
WITH - стандартный SQL

> Зачем здесь with?
Зачем здесь inner join? Почему не in (select ...) ? В ORACLE (до 9) нет join.

← →
ЮЮ © (2006-09-29 11:49) [8]

Почему не in (select ...)

Потому, наверное, что синтаксис, ИМХО
in (select <одно поле> FROM ...), а запрос с группировкой предполагает как минимум 2

Хотя, на MS SQL сработало и без агрегатной функции в Select, а лишь в Having
На paradox-е пробовать неохота

← →
Fay © (2006-09-29 11:59) [9]

2 ЮЮ © (29.09.06 11:49) [8]
> а запрос с группировкой предполагает как минимум 2
Чё, серьёзно?

← →
Fay © (2006-09-29 12:01) [10]

2 ЮЮ © (29.09.06 11:49) [8]
> На paradox-е пробовать неохота
select NAME from animals group by NAME

← →
ЮЮ © (2006-09-29 12:06) [11]

> select NAME from animals group by NAME

Я в таком случае пишу
select DISTINCT NAME from animals

← →
Fay © (2006-09-29 12:09) [12]

2 ЮЮ © (29.09.06 12:06) [11]
> Я в таком случае пишу
Думаю, мы оба понимаем, что на стандарт это не влияет

← →
Johnmen © (2006-09-29 13:20) [13]

> Fay © (29.09.06 11:34) [7]
> WITH - стандартный SQL

Можно ссылку?

← →
Fay © (2006-09-29 13:57) [14]

2 Johnmen © (29.09.06 13:20) [13]
> Можно ссылку?
У меня нет ссылки на стандарт, но у разработчиков Oracle и Postgre SQL есть 8). Во всяком случае, они таких (ниже) ссылок могу привести навалом.
http://www.oracle-training.cc/t_oracle_with_sql.htm

← →
evvcom © (2006-09-29 14:43) [15]

> [7] Fay © (29.09.06 11:34)
> Т.о. решение не противоречит постановке

Ну это верно :)

> WITH - стандартный SQL

Возможно, давно не открывал стандарты. Но реальные сервера поддерживают далеко не всё, что описано в стандартах.В частности with поддерживают раз, два и обчелся серверов-то.

> В ORACLE (до 9) нет join.

inner join - стандартный SQL
В ORACLE (до 9) нет with (AFAIK)

> [8] ЮЮ © (29.09.06 11:49)
> Потому, наверное, что синтаксис, ИМХО
> in (select <одно поле> FROM ...),

не знаю, как в других СУБД и в стандарте, а оракл позволяет
where (fld1, fld2) in (select <2 поля> FROM ...)

← →
Fay © (2006-09-29 14:47) [16]

2 evvcom © (29.09.06 14:43) [15]
> В ORACLE (до 9) нет with (AFAIK)
Не проверял (не было возможности), но на sql.ru один мембер утверждал, что с было и в семёрке.

← →
Fay © (2006-09-29 14:49) [17]

2 evvcom © (29.09.06 14:43) [15]
> не знаю, как в других СУБД и в стандарте, а оракл позволяет
> where (fld1, fld2) in (select <2 поля> FROM ...)
Знаю и помню как меня удивило это знание 8)
Однако, такой IN не подходит для сабжа.

← →
evvcom © (2006-09-29 14:53) [18]

> [17] Fay © (29.09.06 14:49)

Причем, эти in все равно как join сервером воспримутся (в данном случае). Не лучше ли сразу явно join написать?

← →
Johnmen © (2006-09-29 15:17) [19]

> Fay © (29.09.06 13:57) [14]
> У меня нет ссылки на стандарт,

У меня есть стандарт. Про WITH в указанном контексте там ни слова.
А что до Оракла и пр. - нехай как хотят придумывают слова...:)

← →
Fay © (2006-09-29 15:40) [20]

2 Johnmen © (29.09.06 15:17) [19]
> У меня есть стандарт.
SQL-99 ?

← →
Climber © (2006-09-29 16:36) [21]

select ss
from base
where ss in (select ss from base group by ss having count(ss)>10)

повисает. с count(*) тоже. где неверно?

← →
Виталий Панасенко (2006-09-29 16:59) [22]

> Climber © (29.09.06 16:36) [21]
> select ss
> from base
> where ss in (select ss from base group by ss having count(ss)>10)
>
> повисает. с count(*) тоже. где неверно?

Уверен ? Может, просто записей много...

← →
Fay © (2006-09-29 17:05) [23]

Виталий Панасенко (29.09.06 16:59) [22]
а индексов мало 8)

← →
evvcom © (2006-09-29 17:07) [24]

> [21] Climber © (29.09.06 16:36)

Про СУБД так и ни слова?
Я конструкцию in стараюсь не использовать. Частенько оракл воспринимает ее не так как хотелось бы мне. А меняется на join практически всегда очень легко. Попробуй [5]

← →
Виталий Панасенко (2006-09-29 17:11) [25]

А СУБД, похоже, Paradox. В предыдущем посте аффтара этот формат был указан

← →
evvcom © (2006-09-29 17:29) [26]

> [25] Виталий Панасенко (29.09.06 17:11)

Не заметил нигде "формата" Paradox-а. В парадоксе (Local-SQL) вложенный селект вообще не прошел бы. Может, конечно, то что в in интерпретируется не как вложенный селект, фиг знает. Но мне, кажется, в парадоксе такой запрос сообщил бы об ошибке. Проверять лень.

BDE. база FoxPro, досовая.
ни with, ни inner join не проходит..

Не знаю как насчет SQL-99, но для SQL-92 существует как минимум три уровня совместимости, первый должны поддерживать все, кто заявляет об совместимости, а вот дотягивает ли кто ни будь до третьего - не уверен.
Но все бодро заявляют об совместимости.

Если подзапрос возвращает много записей, то IN - тормоза не только для БДЕ.
Если сам подзапрос выполняется за приемлимое время, то предлагаю использовать Local View:

SELECT base.* FRОM
"cnt10.sql" v
JOIN base ON v.ss = base.ss

где cnt10.sql текстовый файл в БД с запросом
select ss from base group by ss having count(ss)>10

З.Ы. Судя по выделенному, индекс по ss в таблице base очень даже не помешает.

выборка существенно ускорилась, но некорректная она, не получается то, что требуется..

2 ЮЮ © (02.10.06 4:04) [29]
> Если подзапрос возвращает много записей, то IN - тормоза не только для БДЕ.
(мягко) Это не совсем правда.

> выборка существенно ускорилась, но некорректная она, не
> получается то, что требуется..

По какому запросу ? Что попало не то? Что не попало, что ожидалось?

> (мягко) Это не совсем правда.

Зачкм так мякго? Это или правда (на некоторых серверах). Или неправда.(на всех серверах)

попадают записи с ss,который встречается и менее 10 раз. В общем по рандому. Не понятно..

> [32] ЮЮ © (03.10.06 05:31)

> Зачкм так мякго? Это или правда (на некоторых серверах).
> Или неправда.(на всех серверах)

Это скорее не от сервера зависит, а от условия - если здоровый подзапрос выполняется для каждой записи основного запроса, то тормоза практически обеспечены, если один раз, то еще не факт.

> попадают записи с ss,который встречается и менее 10 раз

Какой именно запрос выполняешь? Как проверяешь? Попадают эти записи в запрос с условием < 10 ???

этот запрос. + в нем еще выборка WHERE добавлена. Разное число записей для каждого ss попадает. Условию <10 тоже не удовлетворяют.. =|
SELECT base.* FRОM
"cnt10.sql" v
JOIN base ON v.ss = base.ss
где cnt10.sql текстовый файл в БД с запросом
select ss from base group by ss having count(ss)>10

в нем еще выборка WHERE добавлена

Ну и чего ты тогда хочешь? Естественно часть записей отсекается. Если же хочешь, чтобы не менее десятиЮ удовлетворяющих условию, то WHERE надо поместить в подзапрос, в запросе тогда не нужен.

К сожалению, параметры в подзапросах не поддерживаются. Поэтому подзапрос придется постояноо перезаписывать динамически. При многопользовательском режиме следует позаботиться о "разделении доступа" к подзапросам

А где фиксить EDBEngineError "Temporary table resourse limit"?..

GROUP BY Найти похожие ветки