Obecnie robię coś takiego jednak tak naprawdę
select z.uid,z.active,count(*),c.symbol,c.nazwa from z,c where c.uid=z.uid
group by z.uid,z.active,c.symbol,c.nazwa;
Chodzi mi jednak o to, że zupełnie bez sensu agregują się te dane które NIE
MUSZA się już agregować. W sumie można by wyciągnąć dane tak:
select uid,active,count(*) from z group by uid,active;
A potem po kolei sprawdzić iterując po drugiej osobnymi selectami dla
każdego UID.
Szukałem ale nie znalazłem... może ktoś z was wie jak to złączyć sensowniej?
--
Krzysztof Antoń
Hmm...nie za bardzo cie rozumiem
Może wystarczy po prostu:
select z.uid,z.active,count(*)
from z,c
where c.uid=z.uid
group by z.uid,z.active
--
Roger
Bo mi chodzi o uzyskanie takiego wyniku jak tym powyżej moim czyli +
elementy z drugiej tablicy - ale bez bezsensownej agregacji (bo to cały
wiersz który jest jednoznaczny)... chodzi mi o zagregowanie jednej tabeli
takim zapytaniem:
select uid,active,count(*) from z group by uid,active;
I odczytanie na podstawie uidu danych z pierwszej ZACHOWUJĄC jednak dane
uzyskane z agregacji w celu prezentacji tego w jednym wierszu.
--
--
Krzysztof Antoń
Hmmm...chyba się nie rozumiemy
Załóżmy zawartość tababel
Z:
uid|active
1 |1
1 |2
C:
uid|symbol|nazwa
1 |1 |2
1 |3 |4
i teraz po złączeniu tabeli C z Z po polu uid, jakie wartości z
pól symbol i nazwa z tabeli C dla danego uid mają być wyświetlone ?
W zależności od tego co chcesz uzyskać stosujesz albo
grupowanie po tych polach (jak do tej pory robiłeś),
albo wstawiasz je do jakiś funckji agregujących.
W przypadku gdy pole uin w tabeli C jest unikalne to
wtedy jest to bez znaczenia: możesz albo grupować po tych polach
(jak do tej pory robiłeś) albo wstawić je do funkcji agregujących jak MIN
lub MAX
- wynik będzie taki sam.
Nie piszesz jaka baza.
--
Roger
Widzę. Proszę zobacz na mój pierwszy post. Chodzi o to, że mam rozwiązanie i
jest tam przedstawione. Jednak NIE PODOBA Mi się ono bo używa zbędnej
agregacji po polach które nie mają znaczenia. A agregacja jest obowiązkowa
bo inaczej baza wypisuje błąd że zmienna musi być użyta w funkcji
agregującej lub grupującej.
> Załóżmy zawartość tababel
> Z:
> uid|active
> 1 |1
> 1 |2
>
> C:
> uid|symbol|nazwa
> 1 |1 |2
> 1 |3 |4
>
> i teraz po złączeniu tabeli C z Z po polu uid, jakie wartości z
> pól symbol i nazwa z tabeli C dla danego uid mają być wyświetlone ?
> W zależności od tego co chcesz uzyskać stosujesz albo
> grupowanie po tych polach (jak do tej pory robiłeś),
> albo wstawiasz je do jakiś funckji agregujących.
>
> Nie piszesz jaka baza.
Racja - PostgreSQL 7.3.4.
Chodzi mi o to, że mam zapytanie zaagregowane (wyciągnięta jest count(*) po
pewnych polach które są zgrupowane) - i teraz do tego doczepić pozostałe
dane z drugiej tabeli po tym polu które jest identyfikatorem: czyli UID.
Obecnie korzystam z czegoś co bezsensownie agreguje dane dodatkowo które są
niejako słownikiem do tabeli zagregoweanej... jeżeli da się to zrobić
lepiej to czekam na takie wlaśnie bardziej optymalne rozwiązanie.
--
Krzysztof Antoń
Może ci się nie podoba ale tak musi być.
>> Nie piszesz jaka baza.
>
> Racja - PostgreSQL 7.3.4.
>
> Chodzi mi o to, że mam zapytanie zaagregowane (wyciągnięta jest
> count(*) po pewnych polach które są zgrupowane) - i teraz do tego
> doczepić pozostałe dane z drugiej tabeli po tym polu które jest
> identyfikatorem: czyli UID. Obecnie korzystam z czegoś co
> bezsensownie agreguje dane dodatkowo które są niejako słownikiem do
> tabeli zagregoweanej... jeżeli da się to zrobić lepiej to czekam na
> takie wlaśnie bardziej optymalne rozwiązanie.
To wcale nie jest bezsensowne. Zobacz mój przykład z poprzedniego postu
Napisałeś, że tabela C jets słownikowa, czyli pole uid jest w niej unikalne
?
--
Roger
Może ci się nie podoba ale tak musi być.
>
>>> Nie piszesz jaka baza.
>>
>> Racja - PostgreSQL 7.3.4.
>>
>> Chodzi mi o to, że mam zapytanie zaagregowane (wyciągnięta jest
>> count(*) po pewnych polach które są zgrupowane) - i teraz do tego
>> doczepić pozostałe dane z drugiej tabeli po tym polu które jest
>> identyfikatorem: czyli UID.
ech...trzeba bylo od razu tak napisac,
że uid jest kluczem w tabeli C :(
> Obecnie korzystam z czegoś co
>> bezsensownie agreguje dane dodatkowo które są niejako słownikiem do
>> tabeli zagregoweanej... jeżeli da się to zrobić lepiej to czekam na
>> takie wlaśnie bardziej optymalne rozwiązanie.
>
To wcale nie jest bezsensowne. Zobacz mój przykład z poprzedniego
postu. Pola te (z tabeli C) musisz grupować albo wstawić w funkcje
agregujące
Czyli
1) tak jak robiłeś do tej pory z grupowaniem
select z.uid,z.active,count(*),c.symbol,c.nazwa
from z,c
where c.uid=z.uid
group by z.uid,z.active,c.symbol,c.nazwa;
2) z funkcjami agregującymi
select z.uid,z.active,count(*),MAX(c.symbol),MAX(c.nazwa)
from z,c
where c.uid=z.uid
group by z.uid,z.active
3) z dynamicznym widokiem
select a.* ,c.symbol,c.nazwa
from c,
(select uid,active,count(*) as licznik from z group by uid,active) as a
where c.uid=a.uid
I jeżeli, tak jak piszesz, UID w tabeli C jest kluczem,
to wszystkie zapytania zwrócą to samo.
I w cale nie znaczy, że 3) gdzie nie są agregowane pola z
tabeli C będzie najszybsze.
--
Roger
> Może ci się nie podoba ale tak musi być.
Nie musi :-)
>>> Chodzi mi o to, że mam zapytanie zaagregowane (wyciągnięta jest
>>> count(*) po pewnych polach które są zgrupowane) - i teraz do tego
>>> doczepić pozostałe dane z drugiej tabeli po tym polu które jest
>>> identyfikatorem: czyli UID.
Sądziłem, że wynika to z zapytania.
> ech...trzeba bylo od razu tak napisac,
> że uid jest kluczem w tabeli C :(
>
> To wcale nie jest bezsensowne. Zobacz mój przykład z poprzedniego
> postu. Pola te (z tabeli C) musisz grupować albo wstawić w funkcje
> agregujące
Err, oczywiście chodziło mi o bezsensowne grupowanie dodatkowe a nie
agregację. A to co było potrzebne czyli count(*) z danej agregacji w
powiązaniu z danymi z drugiej tabeli udało się zrobić...
A prawidłowa odpowiedz to:
> 3) z dynamicznym widokiem
>
> select a.* ,c.symbol,c.nazwa
> from c,
> (select uid,active,count(*) as licznik from z group by uid,active) as a
> where c.uid=a.uid
> I jeżeli, tak jak piszesz, UID w tabeli C jest kluczem,
> to wszystkie zapytania zwrócą to samo.
> I w cale nie znaczy, że 3) gdzie nie są agregowane pola z
> tabeli C będzie najszybsze.
Właśnie o to zapytanie mi chodziło...
Wielkie Dzięki!!!
--
Krzysztof Antoń
Niestety tu nie ma wróżek i oprócz podania bazy
trzeba jeszcze wszysto dokładnie wytłumaczyć
--
Roger