Inna składnia złączeń z podzapytaniem
Sexbox - 17-03-2006 00:29
Inna składnia złączeń z podzapytaniem
Mam pytanie na ile prawidłowe i wydajne jest poniższe zapytanie select:
SELECT
t.Pole1,
t.Pole2,
s.PoleS1
FROM
Towary as t,
(SELECT * FROM Cechy as t1, Cechy as t2 WHERE t1.ID = t2.ID and ...) as
s
WHERE
...
Cała inność, w tym zapytaniu to że w sekcji FROM zamiast tabeli
jest podzapytanie o aliasie "s".
Żadna z książek z którymi się spotkałem nie przedstawia takiego
wariantu podzapytania, ale przynajmniej na MSSQL Serv 2005 to działa
bez problemu. Czy taka forma wykracza poza standard SQL i jeśli jej użyje
narażam sie na brak przenośności?
__________
Inna kwestia to po co tak konstrukcja? Można by przecież wszystkie tabele
wsadzić
do sekcji FROM. Ale w moim przypadku Te podzapytanie jest samo-złączeniem
tabeli
"Cechy" która zawiera różne dane do tabeli Towarów jak (Producent, Kolor,
Grupa, ...)
Iloczyn kartezjański takiego mega złączenia były olbrzymi.
Natomiast w moim wewnętrznym podzapytaniu bardzo zawężam ilość danych które
muszę
potem złączyć z tabelą Towary.
Wydaje mi się że takie rozwiązanie jest bardziej optymalne, ale może się
mylę.
Może ktoś zweryfikuje mój pogląd.
Pozdrawiam
=?ISO-8859-2?Q?B=B3a=BFej_Strus?= - 17-03-2006 00:29
Sexbox napisał(a):
> Mam pytanie na ile prawidłowe i wydajne jest poniższe zapytanie select:
> ...
> Cała inność, w tym zapytaniu to że w sekcji FROM zamiast tabeli
> jest podzapytanie o aliasie "s".
>
> Żadna z książek z którymi się spotkałem nie przedstawia takiego
> wariantu podzapytania, ale przynajmniej na MSSQL Serv 2005 to działa
> bez problemu. Czy taka forma wykracza poza standard SQL i jeśli jej użyje
> narażam sie na brak przenośności?
Może tak być. Nie wszystkie serwery b-d zezwalają na podzapytania.
Choć raczej jest to już coraz rzadsze zjawisko.
> Inna kwestia to po co tak konstrukcja?
> ...
> Wydaje mi się że takie rozwiązanie jest bardziej optymalne,
> ale może się mylę.
Sam sobie odpowiadasz na powyższe pytanie - żeby było optymalniej.
Są pewne zasady fundamentalne tworzenia optymalnych kwerend, resztę
optymalizuje się pisząc różne konstrukcje i sprawdzając czas wykonania.
Testuj, testuj, testuj. Czasem inner join jest szybszy od umieszczenia
warunków złączenia w sekcji where, czasem odwrotnie.
Jeśli chcesz poznać opinię nt. wydajności Twojego zapytania - przytocz
je w całości. Na podstawie samych sekcji select i from ciężko mówić
o wydajności.
Blazek
=?ISO-8859-2?Q?Pawe=B3_Matejski?= - 17-03-2006 00:29
Użytkownik Sexbox napisał:
> Mam pytanie na ile prawidłowe i wydajne jest poniższe zapytanie select:
>
> SELECT
> t.Pole1,
> t.Pole2,
> s.PoleS1
> FROM
> Towary as t,
> (SELECT * FROM Cechy as t1, Cechy as t2 WHERE t1.ID = t2.ID and ...) as
> s
> WHERE
> ...
>
> Cała inność, w tym zapytaniu to że w sekcji FROM zamiast tabeli
> jest podzapytanie o aliasie "s".
>
> Żadna z książek z którymi się spotkałem nie przedstawia takiego
> wariantu podzapytania, ale przynajmniej na MSSQL Serv 2005 to działa
> bez problemu. Czy taka forma wykracza poza standard SQL i jeśli jej użyje
> narażam sie na brak przenośności?
Jest to najlepszy sposób jesli musisz użyć podzapytania. Najlepszy dlatego,
że podzapytanie wykonuje sie tylko raz, a nie dla każdego wiersza, co ma
najczęściej miejsce przy uzyciu podzapytania w inny miejscu. Przy okazji
dodam, że chyba w kazdym przypadku zapytanie da sie przekształcic tak,
żeby podzapytanie wystąpiło tylko w klauzurze FROM.
> __________
>
> Inna kwestia to po co tak konstrukcja? Można by przecież wszystkie tabele
> wsadzić
> do sekcji FROM. Ale w moim przypadku Te podzapytanie jest samo-złączeniem
> tabeli
> "Cechy" która zawiera różne dane do tabeli Towarów jak (Producent, Kolor,
> Grupa, ...)
> Iloczyn kartezjański takiego mega złączenia były olbrzymi.
> Natomiast w moim wewnętrznym podzapytaniu bardzo zawężam ilość danych które
> muszę
> potem złączyć z tabelą Towary.
> Wydaje mi się że takie rozwiązanie jest bardziej optymalne, ale może się
> mylę.
Jak napisałem powyrzej, takie podzapytanie jest najlepsze *o ile trzeba użyć podzapytania*,
a w Twoim przypadku takiej potrzeby nie ma. Wiekszość baz danych świetnie sobie radzi
z optymalizacja złączeń i nie potrzebują robić pełnego iloczynu kartezjańskiego, aby
wybrac potrzebne rekordy.
> Może ktoś zweryfikuje mój pogląd.
--
P.M.
Sexbox - 17-03-2006 00:29
> Jeśli chcesz poznać opinię nt. wydajności Twojego zapytania - przytocz
> je w całości. Na podstawie samych sekcji select i from ciężko mówić
> o wydajności.
Byłbym wdzięczy za ocenę! Poniżej dwa zapytania.
1.) "Klasyczne" Sklejam Towar+Features+Features
2.) Zapytanie z podzapytaniem Towar+(Features+Features)
* Towary to prosta tablica:
ID|Kod|Nazwa|....
* Features to tablica wiele-do-wielu zawierająca różne cechy towarów,
tu wyciągam tylko Grupę i Producenta ale posiada także np. Kolory,
Rozmiar,...:
Parent(ID Towaru)|ParentType(dodatkowa flaga=Towary)|Name(Nazwa
cechy)|Data(wartośc cechy)
13|Towary|Grupa|Drukarki
13|Towary|Producent|Canon
14|Towary|Grupa|Myszki
1)
SELECT
t.ID, t.Kod, t.Nazwa, f1.Data as Grupa, f2.Data as Producent
FROM
Towary as t
JOIN Features as f1 ON t.ID = f1.Parent and f1.Name = 'Grupa' and
f1.ParentType = 'Towary' -- Grupę ma każdy towar
LEFT OUTER JOIN Features as f2 ON t.ID = f2.Parent and f2.Name =
'Producent' -- ...Producenta niekoniecznie
-- ----------------------------------------------------
2)
SELECT
t.ID, t.Kod, t.Nazwa, ff.Grupa, ff.Producent
FROM
Towary as t,
(
SELECT
f1.Parent as Towar
,f1.Data as Grupa
,f2.Data as Producent
FROM
Features as f1
LEFT OUTER JOIN Features as f2
ON f1.Parent = f2.Parent and f2.Name = 'Producent'
WHERE
f1.Name = 'Grupa'
and f1.ParentType = 'Towary'
) as ff
WHERE
t.ID = ff.Towar
> Testuj, testuj, testuj. Czasem inner join jest szybszy od umieszczenia
> warunków złączenia w sekcji where, czasem odwrotnie.
Z MSSQLem dopiero zaczynam, mam:
MS SQL Serwer 2005 Express Edition + Managment Studio Express
nie bardzo znam te narzędzia, testy robię włączając "Client Statistic"
ale pomiar jest bardzo niedokładny - różne wyniki dla tego samego zapytania
dlatego ciężko porównywać, może znacie jakieś inne narzędzia pomiarowe itp.
Sexbox - 17-03-2006 00:29
> Jak napisałem powyrzej, takie podzapytanie jest najlepsze *o ile trzeba
> użyć podzapytania*,
> a w Twoim przypadku takiej potrzeby nie ma. Wiekszość baz danych świetnie
> sobie radzi
> z optymalizacja złączeń i nie potrzebują robić pełnego iloczynu
> kartezjańskiego, aby
> wybrac potrzebne rekordy.
> [...]
Dzięki za uwagi i sugestie.
Ale jak zajrzysz do mojego drugiego posta to podałem tam moje pełne
zapytanie
plus wersję bez podzapytania (potrójne złączenie).
I z pomiarów (bardzo niedokładnych ale jednak) wersja z pod zapytaniem jest
trochę szybsza. Być może dlatego że w wersji z po trójnym złączeniem
trochę nakombinowane jest w warunkach i kombinacji INNER/OUTER JOIN
ale jednak.
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
[mysql 5.x] jak =?ISO-8859-2?Q?zrealizowa=E6_zapytanie=3F_cz?==?ISO-8859-2?Q?yli_podzapytanie_i_wi=EAcej_ni=BF_jeden_rz=B1? ==?ISO-8859-2?Q?d_wynik=F3w?=
=?ISO-8859-2?Q?wynik_podzapytania_jako_pojedy=F1cza_warto=B6= E6?=
podzapytanie z wyrazeniem IN a przekazanie tego UDFowi, pomoc w zapytaniu
wynik podzapytania jako zmienna - postgresql
=?ISO-8859-2?Q?[MSSQL]_U=BFycie_podzapytania?=
[sql] podzapytanie w klauzuli 'from' - teoria.
wydajnosc, podzapytania czy zapytania?
Wyciągnięcie z podzapytania do zapytania
[MySQL] podzapytanie w petli
[MSSQL] - problem z podzapytaniem
zanotowane.pldoc.pisz.plpdf.pisz.pllisinski.htw.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
