🚀 go-pugleaf

On Thursday, December 10, 2015 at 6:36:10 PM UTC+1, szemrany wrote:
> Witam,
> 
> Mam pytanie o praktykowane przez Was sposoby rozwiązania problemu.
> Mam tabelę, która gromadzi jakiś rodzaj pozycji, te pozycje mogą być
> przypisane do innych bazodanowych obiektów typu osoby, auta, budynki.
> Chciałbym te wszystkie obiekty połączyć czyli:
> 
> auto |-< item
> osoby |-< item
> budynek |-< item
> 
> I teraz... czy lepiej w tabeli pośredniej mieć trzy kolumny:
> 
> Item_Rel
> ---------
> idauto
> idosoba
> idbudynek
> 
> czy też mieć 3 osobne tabele, dla każdej relacji osobno:
> 
> Item_Osoba_Rel
> Item_Auto_Rel
> Item_Budynek_Rel
> 
> ?
> 
> A może jeszcze inaczej?

Nie umiem konkretnie doradzić. Głupio mi też cokolwiek tłumaczyć, ponieważ
nie wiem jest dla Ciebie oczywiste a co nie. ID masz unikalne w skali
bazy czy tabeli? Gdy w skali tabeli, to w przypadku jednej tabeli, jeszcze
musi być pole z info o relacji.

Pozdrawiam

> ID masz unikalne w skali
>bazy czy tabeli? Gdy w skali tabeli, to w przypadku jednej tabeli, jeszcze
>musi być pole z info o relacji.

Jakaś jestem nie kumata dziś, ale nie rozumiem ani pytania oni odpowiedzi.
Zwykle id jest unikalne dla tabeli, nie dla bazy.
Inne rozwiązania wydają mi się prehistoryczne, może zciągnięte z bazy nie 
relacyjnej, a jeszcze sieciowej, czyli z pszed jakihś 30 lat.
We wpułczesnej bazie , czyli poza uczelnią, się z tym nie spotkałam.

Jakie info o relacji?
Baza relacyjna to baza, kturej podstawowymi składnikami są tabele o 
prymitywnej strukturce: czyli nie ma pola opcjonalnie z kilkoma danymi lub 
jedną - rekordu zależnego od samej danej (jak łysy to nie ma danej, a jak 
niełysy, to jeszcze jest kolor włosa). Tak więc w tabeli relacyjnej bazy 
danyh wszystkie rekordy = wiersze mają tę samą strukturę.
Ale tabele mogą być inne, każda może i zwykle jest inna od drugiej.
W jednej będzie 5 kolumn, w innej tylko 2.

Drugą cehą relacyjnej bazy jest jak sama nazwa wskazuje relacja.
Relacja ta ma niewiele wspulnego z matematyczną definicją relacji dotyczącą 
zbioru,
ale pszy pomocy nażędzi matematyki można ją zdefiniować precyzyjnie,
jednak w praktyce progamistycznej nigdy się tego nie robi
i nie jest to potszebne, tylko gmatawa istotę.

Relacja, najczęściej polega na tym, że w jednej tabeli Tabela_Auta mam
np marki aut w postaci 2 kolumn: id_marki, nazwa_marki.
Może być więcej kolum: rok produkcji, producent itp.
W drugiej zaś np Tabela_Garaż będzie położenie, wymiary, czynsz, włąściciel, 
no i nieszczęsne auto.
Można by wpisywać albo auto do każdego wiersza drugiej tabeli,
było by to prawdopodobnie pole tekstowe, i w praktyce ktoś wpisywał by tam:
"zielony trabant".
 A można zamiast wpisywać "zielony trabant" zrobić tak zwane pole kombi,
kture pokaże użytkownikowi listę nazwa_marki z pierwszej tabeli,
a w pole bazy drugiej tabeli wstawi Id_marki.
Dzieki temu:
- użytkownik mam niej pracy, bo wybiera tylko auto z listy,
- baza , tabela_garaż ma mniejszy rozmiar, bo w każym wierszu, zamiast np 50 
lub 100 znakowego opisu jest tylko 4 bajty zajmowane pszez Id_auta.
- jest mniej błędów w bazie, bo zwykle użytkownik nie ma prostej metody na 
wpisanie w miejsce auta: "dwie hulajnogi". Unika się też typowyh błęduw 
literuwek.

Jest najbardziej typowa relacja, i nie ma tu miejsca na żaden opis relacji, 
no może poza dokumentacją.
____
Co do pytania pierwotnego: nie bardzo rozumiem oznaczenia "|-<"
ani co znaczy item.
Ale wydaje mi się , że bym raczej podzieliła.

-- 
_____http://ortografia.ma7.eu_____zmiana adresu strony
w zakładce 'inne', nowa wersja syntezatora mowy GdakMini2_99 ,
z nowym głosem
(tekst bez: ó, ch, rz i -ii) Ortografia to NAWYK, często nielogiczny,
ktury ludzie ociężali umysłowo, nażucają bezmyślnie następnym pokoleniom.

On Friday, December 11, 2015 at 10:23:34 AM UTC+1, Stokrotka wrote:
> > ID masz unikalne w skali
> >bazy czy tabeli? Gdy w skali tabeli, to w przypadku jednej tabeli, jeszcze
> >musi być pole z info o relacji.
> 
> Jakaś jestem nie kumata dziś, ale nie rozumiem ani pytania oni odpowiedzi.
> Zwykle id jest unikalne dla tabeli, nie dla bazy.
Zobacz sekwencje w postgresie.

Pozdrawiam

On Fri, 11 Dec 2015 07:18:15 -0800 (PST), M.M. wrote:

>>> ID masz unikalne w skali
>>>bazy czy tabeli? Gdy w skali tabeli, to w przypadku jednej tabeli, jeszcze
>>>musi być pole z info o relacji.
>> 
>> Jakaś jestem nie kumata dziś, ale nie rozumiem ani pytania oni odpowiedzi.
>> Zwykle id jest unikalne dla tabeli, nie dla bazy.
> Zobacz sekwencje w postgresie.

Jeśli dobrze rozumiem Stokrotkę, to ma na myśli klucz główny, a klucz
główny to nie sekwencja. Sekwencja _może_ być wykorzystana do "zasilania"
primary keya, ale to nie jest tożsame.


-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On Friday, December 11, 2015 at 5:37:40 PM UTC+1, szemrany wrote:
> On Fri, 11 Dec 2015 07:18:15 -0800 (PST), M.M. wrote:
> 
> >>> ID masz unikalne w skali
> >>>bazy czy tabeli? Gdy w skali tabeli, to w przypadku jednej tabeli, jeszcze
> >>>musi być pole z info o relacji.
> >> 
> >> Jakaś jestem nie kumata dziś, ale nie rozumiem ani pytania oni odpowiedzi.
> >> Zwykle id jest unikalne dla tabeli, nie dla bazy.
> > Zobacz sekwencje w postgresie.
> 
> Jeśli dobrze rozumiem Stokrotkę, to ma na myśli klucz główny, a klucz
> główny to nie sekwencja. Sekwencja _może_ być wykorzystana do "zasilania"
> primary keya, ale to nie jest tożsame.

Myślałem że to będzie oczywiste, że klucz główny nie jest tożsamy z
sekwencją :) Sekwencje nawet 30 lat temu nie były tożsame z kluczem
głównym :)

> Mam tabelę, która gromadzi jakiś rodzaj pozycji
Powiedzmy, że masz tagi, bo pasują (chyba?) do każdego przykładu.

> I teraz... czy lepiej w tabeli pośredniej mieć trzy kolumny: 
> czy też mieć 3 osobne tabele, dla każdej relacji osobno:

Jeśli zostanie zastosowane unikalne id w skali bazy danych, to będzie
można rozwiązać to zadanie przy użyciu jednej tabeli jednokolumnowej.
Nawet jeśli nie zostanie użyte unikalne id w skali bazy, to można
rozwiązać w oparciu o tabelę z jednym id (zamiast tamtych trzech, bo
wiadomo, mogą być inne id potrzebne), o ile jeszcze użyjesz pola z
nazwą (lub enum) tabeli.

Dla id unikalnego w skali bazy
id własne
id tabeli pierwszej
id tabeli drugiej
Zaleta: wystarczy taka jedna tabela na całą bazę.

Drugie rozwiązanie
id własne
id tabeli pierwszej
id tabeli drugiej
nazwa tabeli

Trzecie rozwiązanie:
id własne
id tabeli pierwszej
id tabeli drugiej lub null
id tabeli trzeciej lub null
id tabeli czwartej lub null

Czwarte rozwiązanie:
Tabela 1
id własne
id tabeli pierwszej
id tabeli drugiej
Tabela 2
id własne
id tabeli pierwszej
id tabeli trzeciej
Tabela 3
id własne
id tabeli pierwszej
id tabeli czwartej

Które wybrać, zależy od tego jak będziesz używał. Mnie się podoba rozwiązanie
pierwsze i czwarte, drugie trochę mniej, a trzecie w ogóle mi się nie
podoba :)

Pozdrawiam

On Fri, 11 Dec 2015 10:15:40 -0800 (PST), M.M. wrote:

>> Mam tabelę, która gromadzi jakiś rodzaj pozycji
> Powiedzmy, że masz tagi, bo pasują (chyba?) do każdego przykładu.

Niezupełnie, tag jest informacją sam w sobie, a mój "item" to więcej
danych, które są w osobnej tabeli.
 
>> I teraz... czy lepiej w tabeli pośredniej mieć trzy kolumny: 
>> czy też mieć 3 osobne tabele, dla każdej relacji osobno:
> 
> Jeśli zostanie zastosowane unikalne id w skali bazy danych, to będzie
> można rozwiązać to zadanie przy użyciu jednej tabeli jednokolumnowej.

??
W jednokolumnowej tabeli zrobisz powiązanie czegoś czymś? Jak?

> Nawet jeśli nie zostanie użyte unikalne id w skali bazy, to można
> rozwiązać w oparciu o tabelę z jednym id (zamiast tamtych trzech, bo
> wiadomo, mogą być inne id potrzebne), o ile jeszcze użyjesz pola z
> nazwą (lub enum) tabeli.
> 
> Dla id unikalnego w skali bazy
> id własne
> id tabeli pierwszej
> id tabeli drugiej
> Zaleta: wystarczy taka jedna tabela na całą bazę.

Tego też nie ograniam, powyżej masz dwa id (np. auto, budynek), a co z
trzecim? 

Opisz to jaśniej proszę.

-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

> W jednokolumnowej tabeli zrobisz powiązanie czegoś czymś? Jak?
Przepraszam, zagalopowałem się, moja pomyłka. Chodziło mi o to, żeby
użyć jednej kolumny zamiast tamtych trzech, nie wiem czemu tak 
ogólnie napisałem.


> Opisz to jaśniej proszę. 
Wróćmy do podstaw. Bardziej realny przykład. Tagi są zle, więc mamy
cztery tabele:
Ludzie
Samochody
Domy
Działki

Każdy człowiek może mieć 0 lub więcej samochodów, domów i działek, racja?

Więc mamy tabelę łączącą:
Zasoby
id_własne
id_1
id_2

Przykład zapytania
(nie kompilowałem, z góry sorry za błędy)

select 
   *, 
   (
   select 
     count(*) 
   from 
     Zasoby as Z 
   where 
     Z.id_1 = L.id
   AND
     Z.id_2 IN
     (
     select id from samochody
     )
  ) 
  AS ilosc_samochodow
  from 
Ludzie as L;

Proszę, zwróć tylko uwagę, że gdzieś wyżej napisałem jedynie 'można', a nic 
nie piszę na temat tego, czy to jest dobre czy złe rozwiązanie. Analogicznym
zapytaniem można sprawdzić ilu współwłaścicieli ma samochód, etc.

Pozdrawiam

On Sat, 12 Dec 2015 04:45:23 -0800 (PST), M.M. wrote:

>> Opisz to jaśniej proszę. 
> Wróćmy do podstaw. Bardziej realny przykład. Tagi są zle, więc mamy
> cztery tabele:
> Ludzie
> Samochody
> Domy
> Działki
> 
> Każdy człowiek może mieć 0 lub więcej samochodów, domów i działek, racja?
> 
> Więc mamy tabelę łączącą:
> Zasoby
> id_własne
> id_1
> id_2
> 
> Przykład zapytania
> (nie kompilowałem, z góry sorry za błędy)
> 
> select 
>    *, 
>    (
>    select 
>      count(*) 
>    from 
>      Zasoby as Z 
>    where 
>      Z.id_1 = L.id
>    AND
>      Z.id_2 IN
>      (
>      select id from samochody
>      )
>   ) 
>   AS ilosc_samochodow
>   from 
> Ludzie as L;

Tak, teraz kumam.
Choć akurat tego typu zapytanie będzie mega zabójcze dla serwera, zgon do
kwadratu ;-)

Ale z joinami może dało by się coś sensownego spreparować, sprawdzę
później. 
 
> Proszę, zwróć tylko uwagę, że gdzieś wyżej napisałem jedynie 'można', a nic 
> nie piszę na temat tego, czy to jest dobre czy złe rozwiązanie. Analogicznym
> zapytaniem można sprawdzić ilu współwłaścicieli ma samochód, etc.

Uhm... dzięki za pomysł z unikalnym kluczem.

-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On Saturday, December 12, 2015 at 6:03:36 PM UTC+1, szemrany wrote:
> On Sat, 12 Dec 2015 04:45:23 -0800 (PST), M.M. wrote:
> 
> >> Opisz to jaśniej proszę. 
> > Wróćmy do podstaw. Bardziej realny przykład. Tagi są zle, więc mamy
> > cztery tabele:
> > Ludzie
> > Samochody
> > Domy
> > Działki
> > 
> > Każdy człowiek może mieć 0 lub więcej samochodów, domów i działek, racja?
> > 
> > Więc mamy tabelę łączącą:
> > Zasoby
> > id_własne
> > id_1
> > id_2
> > 
> > Przykład zapytania
> > (nie kompilowałem, z góry sorry za błędy)
> > 
> > select 
> >    *, 
> >    (
> >    select 
> >      count(*) 
> >    from 
> >      Zasoby as Z 
> >    where 
> >      Z.id_1 = L.id
> >    AND
> >      Z.id_2 IN
> >      (
> >      select id from samochody
> >      )
> >   ) 
> >   AS ilosc_samochodow
> >   from 
> > Ludzie as L;
> 
> Tak, teraz kumam.
> Choć akurat tego typu zapytanie będzie mega zabójcze dla serwera, zgon do
> kwadratu ;-)
> 
> Ale z joinami może dało by się coś sensownego spreparować, sprawdzę
> później. 
Zależy jak dany silnik optymalizuje wyszukiwanie. Zaproponowane przeze mnie
wyżej rozwiązanie też można zaindeksować. Jeśli silnik nie ma lepszego
mechanizmu niż indeksy, to inne rozwiązanie też będzie zabójcze.
Wyszukiwanie przez index hash jest bardzo szybkie, więc inne rozwiązania
będą szybsze maksymalnie 3-4 razy i to tylko na silnikach które mają
coś lepszego niż indeksy.

Pozdrawiam

On Sat, 12 Dec 2015 10:09:20 -0800 (PST), M.M. wrote:

> On Saturday, December 12, 2015 at 6:03:36 PM UTC+1, szemrany wrote:
>> On Sat, 12 Dec 2015 04:45:23 -0800 (PST), M.M. wrote:
>> 
>>>> Opisz to jaśniej proszę. 
>>> Wróćmy do podstaw. Bardziej realny przykład. Tagi są zle, więc mamy
>>> cztery tabele:
>>> Ludzie
>>> Samochody
>>> Domy
>>> Działki
>>> 
>>> Każdy człowiek może mieć 0 lub więcej samochodów, domów i działek, racja?
>>> 
>>> Więc mamy tabelę łączącą:
>>> Zasoby
>>> id_własne
>>> id_1
>>> id_2
>>> 
>>> Przykład zapytania
>>> (nie kompilowałem, z góry sorry za błędy)
>>> 
>>> select 
>>>    *, 
>>>    (
>>>    select 
>>>      count(*) 
>>>    from 
>>>      Zasoby as Z 
>>>    where 
>>>      Z.id_1 = L.id
>>>    AND
>>>      Z.id_2 IN
>>>      (
>>>      select id from samochody
>>>      )
>>>   ) 
>>>   AS ilosc_samochodow
>>>   from 
>>> Ludzie as L;
>> 
>> Tak, teraz kumam.
>> Choć akurat tego typu zapytanie będzie mega zabójcze dla serwera, zgon do
>> kwadratu ;-)
>> 
>> Ale z joinami może dało by się coś sensownego spreparować, sprawdzę
>> później. 
> Zależy jak dany silnik optymalizuje wyszukiwanie. Zaproponowane przeze mnie
> wyżej rozwiązanie też można zaindeksować. Jeśli silnik nie ma lepszego

Indeksy indeksami, ale to zapytanie jest zbudowane w ten sposób, że dla
każdego wybranego wiersza z tabeli Ludzie wykonuje dwa zapytania w tabelach
Zasoby i Samochody, ergo jeśli Ludzi masz tysiąc to to _jedno zapytanie_
wykona ponad 2 tysiące zapytań w tle!

> mechanizmu niż indeksy, to inne rozwiązanie też będzie zabójcze.
> Wyszukiwanie przez index hash jest bardzo szybkie, więc inne rozwiązania
> będą szybsze maksymalnie 3-4 razy i to tylko na silnikach które mają
> coś lepszego niż indeksy.

Inne rozwiązania będą szybsze setki razy :-)


PS. oczywiście mogę nie wiedzieć, że istnieje serwer SQL, który zrozumie co
autor miał na myśli i wykona to zapytanie zupełnie inaczej niż autor mu
kazał.

-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On Saturday, December 12, 2015 at 7:25:45 PM UTC+1, szemrany wrote:
> > mechanizmu niż indeksy, to inne rozwiązanie też będzie zabójcze.
> > Wyszukiwanie przez index hash jest bardzo szybkie, więc inne rozwiązania
> > będą szybsze maksymalnie 3-4 razy i to tylko na silnikach które mają
> > coś lepszego niż indeksy.
> 
> Inne rozwiązania będą szybsze setki razy :-)
Analiza jest skomplikowana. Na czas zapytania składa się kilka czynników:
1) Transfer danych
2) Parsowanie zapytania
3) Optymalizowanie i sposób wykonania.
4) Dostępy do danych w buforze ram
5) Dostępy do danych na dysku
6) Odczyty danych z dysku.

Jeden dysk (SSD) ma 100tys dostępów na sekundę, drugi tylko 100. Każda
strategia na każdym dysku da inne przyspieszenie.

Spójrzmy skrótowo. Dostęp do danych zaindeksowanych wymaga 3-4 odczytow z
dysku. Dostęp optymalny wymaga jednego odczytu. Czyli teoretycznie można
przyspieszyć nie więcej niż 3-4 razy. A jeśli optymalizator opracuje
tak kosztowny plan wykonania że faktycznie można przyspieszyć setki
razy, to mi ręce opadają i używam innego rozwiązania.


> PS. oczywiście mogę nie wiedzieć, że istnieje serwer SQL, który zrozumie co
> autor miał na myśli i wykona to zapytanie zupełnie inaczej niż autor mu
> kazał.
Od tego jest optymalizator, żeby zrobić tę robotę za autora. Dopracujesz
szczegóły, baza zmieni zawartość i architekturę i znowu będziesz dopracowywał?
To ja wolę dopracować np. w C++.


Pozdrawiam

On Sat, 12 Dec 2015 10:52:51 -0800 (PST), M.M. wrote:

>>> mechanizmu niż indeksy, to inne rozwiązanie też będzie zabójcze.
>>> Wyszukiwanie przez index hash jest bardzo szybkie, więc inne rozwiązania
>>> będą szybsze maksymalnie 3-4 razy i to tylko na silnikach które mają
>>> coś lepszego niż indeksy.
>> 
>> Inne rozwiązania będą szybsze setki razy :-)
> Analiza jest skomplikowana. Na czas zapytania składa się kilka czynników:
> 1) Transfer danych
> 2) Parsowanie zapytania
> 3) Optymalizowanie i sposób wykonania.
> 4) Dostępy do danych w buforze ram
> 5) Dostępy do danych na dysku
> 6) Odczyty danych z dysku.

Ok, ok, ale... to wszystko bez znaczenia, bo występuje w każdym wypadku.
Pisząc o "innych rozwiązaniach" miałem na myśli inaczej zbudowany SQL
(select), niż to co pokazałeś. Bo albo ja nie rozumiem co masz na myśli,
albo Ty nie rozumiesz jak serwer tego typu zapytanie wykonuje.

> Jeden dysk (SSD) ma 100tys dostępów na sekundę, drugi tylko 100. Każda
> strategia na każdym dysku da inne przyspieszenie.

Mówimy cały czas o jednym i niezmiennym środowisku, porównywanie wydajności
rozwiązania na różnym hardware jest bezcelowe i bezowocne.
 
> Spójrzmy skrótowo. Dostęp do danych zaindeksowanych wymaga 3-4 odczytow z
> dysku. Dostęp optymalny wymaga jednego odczytu. Czyli teoretycznie można
> przyspieszyć nie więcej niż 3-4 razy. A jeśli optymalizator opracuje
> tak kosztowny plan wykonania że faktycznie można przyspieszyć setki
> razy, to mi ręce opadają i używam innego rozwiązania.

Chodziło o zwykłe:

select L.imie, L.Nazwisko, count(z.id) as liczba_samochodow from Ludzie L
join zasoby z on z.id_1 = L.id
join samochody s on s.id = z.id_2 
group by L.imie, L.nazwisko
 
Tylko dzięki takiej budowie zapytania (w przeciwieństwie do Twojego)
zyskujesz potwornie na wydajności. 

>> PS. oczywiście mogę nie wiedzieć, że istnieje serwer SQL, który zrozumie co
>> autor miał na myśli i wykona to zapytanie zupełnie inaczej niż autor mu
>> kazał.
> Od tego jest optymalizator, żeby zrobić tę robotę za autora. Dopracujesz
> szczegóły, baza zmieni zawartość i architekturę i znowu będziesz dopracowywał?
> To ja wolę dopracować np. w C++.

No wiesz, nie wszystko się da jednak zoptymalizować. Programista też musi
myśleć. Doczytałem, że Oracle coś tam umie keszować przy zapytaniu tego
typu jaki zaprezentowałeś (nazywają to scalar subquery), ale warunkiem jest
powtarzalność rekordów z tabeli bazowej (tu: Ludzie), a to nie zawsze jest
spełniony warunek (tu nie jest).

-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On Saturday, December 12, 2015 at 10:01:33 PM UTC+1, szemrany wrote:
> On Sat, 12 Dec 2015 10:52:51 -0800 (PST), M.M. wrote:
> 
> >>> mechanizmu niż indeksy, to inne rozwiązanie też będzie zabójcze.
> >>> Wyszukiwanie przez index hash jest bardzo szybkie, więc inne rozwiązania
> >>> będą szybsze maksymalnie 3-4 razy i to tylko na silnikach które mają
> >>> coś lepszego niż indeksy.
> >> 
> >> Inne rozwiązania będą szybsze setki razy :-)
> > Analiza jest skomplikowana. Na czas zapytania składa się kilka czynników:
> > 1) Transfer danych
> > 2) Parsowanie zapytania
> > 3) Optymalizowanie i sposób wykonania.
> > 4) Dostępy do danych w buforze ram
> > 5) Dostępy do danych na dysku
> > 6) Odczyty danych z dysku.
> 
> Ok, ok, ale... to wszystko bez znaczenia, bo występuje w każdym wypadku.
Nie nie. Masz dwa zapytania. Jedno 'zwykłe' drugie 'zoptymalizowane' 
Odpalasz na jednym sprzęcie: zoptymalizowane działa 10 razy szybciej. Na
drugim sprzęcie: zoptymalizowane działa 3 razy szybciej. Sprzęt ma
duży wpływ na to 'ile razy będzie szybciej'.


> Pisząc o "innych rozwiązaniach" miałem na myśli inaczej zbudowany SQL
> (select), 
Tak właśnie zrozumiałem.


> niż to co pokazałeś. Bo albo ja nie rozumiem co masz na myśli,
> albo Ty nie rozumiesz jak serwer tego typu zapytanie wykonuje.
Trochę rozumiem, trochę się domyślam... Szczegółów na pewno
nie rozumiem. Warto rozumieć szczegóły? Jeśli masz ochotę, 
chętnie zobaczę Twoje zapytanie vs moje i uzasadnienie dlaczego
Twoje nie zabije serwera. Może warto się czegoś nauczyć, ale
póki co, dla mnie baza sql to czarna skrzynka, która ma
dobrze działać.



> > Jeden dysk (SSD) ma 100tys dostępów na sekundę, drugi tylko 100. Każda
> > strategia na każdym dysku da inne przyspieszenie.
> 
> Mówimy cały czas o jednym i niezmiennym środowisku, porównywanie wydajności
> rozwiązania na różnym hardware jest bezcelowe i bezowocne.
Ja z kolei zmierzałem do tego, że bezcelowe jest mówienie o przyspieszeniu
np. 100-krotnym, bez uwzględnienia sprzętu :)



> > Spójrzmy skrótowo. Dostęp do danych zaindeksowanych wymaga 3-4 odczytow z
> > dysku. Dostęp optymalny wymaga jednego odczytu. Czyli teoretycznie można
> > przyspieszyć nie więcej niż 3-4 razy. A jeśli optymalizator opracuje
> > tak kosztowny plan wykonania że faktycznie można przyspieszyć setki
> > razy, to mi ręce opadają i używam innego rozwiązania.
> 
> Chodziło o zwykłe:
> 
> select L.imie, L.Nazwisko, count(z.id) as liczba_samochodow from Ludzie L
> join zasoby z on z.id_1 = L.id
> join samochody s on s.id = z.id_2 
> group by L.imie, L.nazwisko
>  
> Tylko dzięki takiej budowie zapytania (w przeciwieństwie do Twojego)
> zyskujesz potwornie na wydajności. 
Tak myślałem że to masz na myśli, nie mam bladego pojęcia, jakie jest
uzasadnienie, że Twoja wersja zyskuje potwornie na wydajności. Powiem
więcej, w pewnym momencie wyrzuciłem z pamięci swoje doświadczenia z
optymalizacji zapytań, bo mialem sprzeczne wyniki testów, albo wyniki
były bardzo wrażliwe na ilość danych i architekturę bazy. Uznałem że
lepiej bazę traktować jako czarną skrzynkę.


> No wiesz, nie wszystko się da jednak zoptymalizować. Programista też musi
> myśleć. Doczytałem, że Oracle coś tam umie keszować przy zapytaniu tego
> typu jaki zaprezentowałeś (nazywają to scalar subquery), ale warunkiem jest
> powtarzalność rekordów z tabeli bazowej (tu: Ludzie), a to nie zawsze jest
> spełniony warunek (tu nie jest).
Cóż, nie rozumiem za wiele z tego. W każdej bazie ustawia się pamięć na
bufor. Ba, każdy system plików może być buforowany przez system operacyjny. Ba,
każdy dysk może mieć swój bufor, a i kontroler dysku może mieć swój bufor.
Piszesz o jakimś jednym buforze w jednej konkretnej bazie - ja nie wiem
dlaczego warto się tym zainteresować. 

Pozdrawiam

>
>Spójrzmy skrótowo. Dostęp do danych zaindeksowanych wymaga 3-4 odczytow z
>dysku. Dostęp optymalny wymaga jednego odczytu. Czyli teoretycznie można
>przyspieszyć nie więcej niż 3-4 razy. A jeśli optymalizator opracuje
>tak kosztowny plan wykonania że faktycznie można przyspieszyć setki
>razy, to mi ręce opadają i używam innego rozwiązania.

Nie całkiem. Jeśli losowo ujmując wymagasz 3-4 dostepuw do danuh,
to wcale statystyczna praktyka nie musi tego potwierdzić.
Jest takie prawo dotyczące systemuw operacyjnyh, że jak jakaś dana jest 
pobierana, to prawdopodobieństwo, że niedługo będzie pobierana ta sama dana 
ponownie, lub, inna dana, ale jej bardzo bliska.
Projektanci Systemuw Operacyjnyh używają tego prawa,
dzieki temu wcale te 3-4 razy nie muszą być prawdziwe,
a docelowo może być tez jeden dostęp albo 1,5 itp.

-- 
_____http://ortografia.ma7.eu_____zmiana adresu strony
w zakładce 'inne', nowa wersja syntezatora mowy GdakMini2_99 ,
z nowym głosem
(tekst bez: ó, ch, rz i -ii) Ortografia to NAWYK, często nielogiczny,
ktury ludzie ociężali umysłowo, nażucają bezmyślnie następnym pokoleniom.

On Sunday, December 13, 2015 at 3:08:51 PM UTC+1, Stokrotka wrote:
> >
> >Spójrzmy skrótowo. Dostęp do danych zaindeksowanych wymaga 3-4 odczytow z
> >dysku. Dostęp optymalny wymaga jednego odczytu. Czyli teoretycznie można
> >przyspieszyć nie więcej niż 3-4 razy. A jeśli optymalizator opracuje
> >tak kosztowny plan wykonania że faktycznie można przyspieszyć setki
> >razy, to mi ręce opadają i używam innego rozwiązania.
> 
> Nie całkiem. Jeśli losowo ujmując wymagasz 3-4 dostepuw do danuh,
> to wcale statystyczna praktyka nie musi tego potwierdzić.
> Jest takie prawo dotyczące systemuw operacyjnyh, że jak jakaś dana jest 
> pobierana, to prawdopodobieństwo, że niedługo będzie pobierana ta sama dana 
> ponownie, lub, inna dana, ale jej bardzo bliska.
> Projektanci Systemuw Operacyjnyh używają tego prawa,
> dzieki temu wcale te 3-4 razy nie muszą być prawdziwe,
> a docelowo może być tez jeden dostęp albo 1,5 itp.

Ile dostępów jest gdy się zastosuje index hash albo btree?

On Saturday, December 12, 2015 at 10:01:33 PM UTC+1, szemrany wrote:
> Chodziło o zwykłe:
> 
> select L.imie, L.Nazwisko, count(z.id) as liczba_samochodow from Ludzie L
> join zasoby z on z.id_1 = L.id
> join samochody s on s.id = z.id_2 
> group by L.imie, L.nazwisko

Nie odpowiedziałeś, a wyjątkowo bardzo zależy mi na odpowiedzi. Więc 
ponawiam pytanie: jakie jest uzasadnienie, że Twoje zapytanie będzie 
szybsze?  

Pozdrawiam

On Mon, 14 Dec 2015 03:08:17 -0800 (PST), M.M. wrote:

> Nie odpowiedziałeś, a wyjątkowo bardzo zależy mi na odpowiedzi. Więc 
> ponawiam pytanie: jakie jest uzasadnienie, że Twoje zapytanie będzie 
> szybsze?  

Chwilowo jestem zajęty, ale odpiszę. Słowo harcerza ;-)


-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On Monday, December 14, 2015 at 4:02:12 PM UTC+1, szemrany wrote:
> On Mon, 14 Dec 2015 03:08:17 -0800 (PST), M.M. wrote:
> 
> > Nie odpowiedziałeś, a wyjątkowo bardzo zależy mi na odpowiedzi. Więc 
> > ponawiam pytanie: jakie jest uzasadnienie, że Twoje zapytanie będzie 
> > szybsze?  
> 
> Chwilowo jestem zajęty, ale odpiszę. Słowo harcerza ;-)
ok

>> Nie całkiem. Jeśli losowo ujmując wymagasz 3-4 dostepuw do danuh,
>> to wcale statystyczna praktyka nie musi tego potwierdzić.
>> Jest takie prawo dotyczące systemuw operacyjnyh, że jak jakaś dana jest
>> pobierana, to prawdopodobieństwo, że niedługo będzie pobierana ta sama 
>> dana
>> ponownie, lub, inna dana, ale jej bardzo bliska.
>> Projektanci Systemuw Operacyjnyh używają tego prawa,
>> dzieki temu wcale te 3-4 razy nie muszą być prawdziwe,
>> a docelowo może być tez jeden dostęp albo 1,5 itp.

>Ile dostępów jest gdy się zastosuje index hash albo btree?

To nie na temat. Wspułczesne bazy danyh nie używają już tak prymitywnyh 
struktur.
Nie wiem też co masz na myśli pod nazwą btree? dżewo binarne czy B- dżewo, a 
to całkiem co innego. Tak czy siak, obie te struktury są już dawno pobite 
pszez algorytmy o lepszej złożoności.
Struktury typu hasz są często wykożystaywane, ale na innym poziomie:
pszez programistę, gdy danyh z punktu widzenia komputera jest mało,
a postawiony problem logicznie pasuje do haszowania. Czyli po prostu gdy tak 
jest wygodnie bez rozczulania się nad szybkością.

-- 
_____http://ortografia.ma7.eu_____zmiana adresu strony
w zakładce 'inne', nowa wersja syntezatora mowy GdakMini2_99 ,
z nowym głosem
(tekst bez: ó, ch, rz i -ii) Ortografia to NAWYK, często nielogiczny,
ktury ludzie ociężali umysłowo, nażucają bezmyślnie następnym pokoleniom.

On Monday, December 14, 2015 at 6:45:44 PM UTC+1, Stokrotka wrote:
> To nie na temat. 
Nie zaszkodzi na chwilę zmienić temat.

> Wspułczesne bazy danyh nie używają już tak prymitywnyh struktur.
To powiedz mi, dlaczego w postgresie pisze się typ indeksu np. btree lub hash?
Nie jest współczesny? Czy te nazwy są dla zmyłki?


> Nie wiem też co masz na myśli pod nazwą btree? 
Dowolną sensowną odmianę btree.


>? dżewo binarne czy B- dżewo, a 
Btree binarne? To chyba jakieś zdegenerowane, czy cos?


> to całkiem co innego. Tak czy siak, obie te struktury są już dawno pobite 
> pszez algorytmy o lepszej złożoności.
Hmmm nie wiedziałem. Co to za algorytmy i jaka jest ich złożoność?


> Struktury typu hasz są często wykożystaywane, ale na innym poziomie:
> pszez programistę, gdy danyh z punktu widzenia komputera jest mało,
> a postawiony problem logicznie pasuje do haszowania. Czyli po prostu gdy tak 
> jest wygodnie bez rozczulania się nad szybkością.
Dlaczego?


Pozdrawiam

>>? dżewo binarne czy B- dżewo, a
>Btree binarne? To chyba jakieś zdegenerowane, czy cos?
Dżewo binarne to jedna z prostszyh struktur danyh,
więc raczej pszodek B-dżewa, a nie degenerat.


>> to całkiem co innego. Tak czy siak, obie te struktury są już dawno pobite
>> pszez algorytmy o lepszej złożoności.
> Hmmm nie wiedziałem. Co to za algorytmy i jaka jest ich złożoność?

Wiesz nie pamiętam, ale pisałam w pobliżu tego tematu pracę magisterską.
O złożoności znajdowania wszystkih spujnyh składowyh (czyli mniej więcej 
dżew w lesie). Wtedy najnowsze algorytmy były dużo lepsze od powszehnie 
pszyjętyh w podręczniku.


>> Struktury typu hasz są często wykożystaywane, ale na innym poziomie:
>> pszez programistę, gdy danyh z punktu widzenia komputera jest mało,
>> a postawiony problem logicznie pasuje do haszowania. Czyli po prostu gdy 
>> tak
>> jest wygodnie bez rozczulania się nad szybkością.
>Dlaczego?
To jest oczywiste, że programista anlizując problem wybiera rozwiązanie 
prostsze i logicznie powiązane z samym problemem.

-- 
_____http://ortografia.ma7.eu_____zmiana adresu strony
w zakładce 'inne', nowa wersja syntezatora mowy GdakMini2_99 ,
z nowym głosem
(tekst bez: ó, ch, rz i -ii) Ortografia to NAWYK, często nielogiczny,
ktury ludzie ociężali umysłowo, nażucają bezmyślnie następnym pokoleniom.

On Tuesday, December 15, 2015 at 12:22:17 PM UTC+1, Stokrotka wrote:
> >>? dżewo binarne czy B- dżewo, a
> >Btree binarne? To chyba jakieś zdegenerowane, czy cos?
> Dżewo binarne to jedna z prostszyh struktur danyh,
> więc raczej pszodek B-dżewa, a nie degenerat.
> 
> 
> >> to całkiem co innego. Tak czy siak, obie te struktury są już dawno pobite
> >> pszez algorytmy o lepszej złożoności.
> > Hmmm nie wiedziałem. Co to za algorytmy i jaka jest ich złożoność?
> 
> Wiesz nie pamiętam, ale pisałam w pobliżu tego tematu pracę magisterską.
> O złożoności znajdowania wszystkih spujnyh składowyh (czyli mniej więcej 
> dżew w lesie). Wtedy najnowsze algorytmy były dużo lepsze od powszehnie 
> pszyjętyh w podręczniku.
> 
> 
> >> Struktury typu hasz są często wykożystaywane, ale na innym poziomie:
> >> pszez programistę, gdy danyh z punktu widzenia komputera jest mało,
> >> a postawiony problem logicznie pasuje do haszowania. Czyli po prostu gdy 
> >> tak
> >> jest wygodnie bez rozczulania się nad szybkością.
> >Dlaczego?
> To jest oczywiste, że programista anlizując problem wybiera rozwiązanie 
> prostsze i logicznie powiązane z samym problemem.

Czytam i czytam Twoje posty od jakiegoś czasu i nie widzę gdzie
odpowiedziałaś na moje pytanie: ile jest dostępów do dysków przy
użyciu btree lub hash?

Pozdrawiam

>Czytam i czytam Twoje posty od jakiegoś czasu i nie widzę gdzie
>odpowiedziałaś na moje pytanie: ile jest dostępów do dysków przy
>użyciu btree lub hash?


Nie ma to bezpośredniego związku z wybraną strukturą danyh, bo zalezne jest 
od ilości pamięci operacyjnej, systemu operacyjnego, jego konfiguracji, a 
także samego silnika bazy danyh.
Sam dysk jest zbyt daleko od struktury danyh.
Dlatego rozważania teoretuczne nie zajmują się takimi pytaniami: ile dostęuw 
do dysku, a częściej poruwnują złozoność rużnyh algorytmuw.
Zwykle złożoność określa się czy on ma stałą złozoność (niezależną od ilości 
danyh), liniową, wykładnicza , kwadratową , logarytmiczną itp.
Ale nie wynika z tego bezpośrednio ilość dostępuw do dysku.
Obecnie wydaje mi się żaden dysk nie pracuje z zasdy pszez pobieranie 
pojednyńczego bajtu do pamęci operacyjnej lub rejestru, a pobiera całą 
stronę, czyli ciąg danyh, a tam może być wiele danyh akurat niebędnyh do 
wykonania obliczeń.


-- 
_____http://ortografia.ma7.eu_____zmiana adresu strony
w zakładce 'inne', nowa wersja syntezatora mowy GdakMini2_99 ,
z nowym głosem
(tekst bez: ó, ch, rz i -ii) Ortografia to NAWYK, często nielogiczny,
ktury ludzie ociężali umysłowo, nażucają bezmyślnie następnym pokoleniom.

On Wednesday, December 16, 2015 at 10:59:57 AM UTC+1, Stokrotka wrote:
> >Czytam i czytam Twoje posty od jakiegoś czasu i nie widzę gdzie
> >odpowiedziałaś na moje pytanie: ile jest dostępów do dysków przy
> >użyciu btree lub hash?
> 
> 
> Nie ma to bezpośredniego związku z wybraną strukturą danyh, 
Bezpośredni czy nie, ma to związek. Pytam o to tak natrętnie dlatego, żeby
zbadać temat 'przyspieszenie o setki razy'. Przy btree ilość dostępów
pesymistycznie wynosić może np. Log500(N) gdzie N to ilość danych.
Dla jednego terabajta rekordów daje to pesymistycznie 5 dostępów.

> bo zalezne jest 
> od ilości pamięci operacyjnej, systemu operacyjnego, jego konfiguracji, a 
> także samego silnika bazy danyh.
Ok, weźmy pod uwagę i ten szczegół, ale pamiętajmy, że to może jedynie
zmniejszyć te 5 dostępów do np. 2 albo 3.


> Sam dysk jest zbyt daleko od struktury danyh.
Tego zupełnie nie rozumiem. Btree jest zapisane na dysku, jak można
powiedzieć, że jest daleko?


> Dlatego rozważania teoretuczne nie zajmują się takimi pytaniami: ile dostęuw 
> do dysku, a częściej poruwnują złozoność rużnyh algorytmuw.
Wybacz, użyłem takiego skrótu myślowego. Pisząc ile btree ma dostępów, miałem
na myśli ile dostępów jest potrzebne w algorytmie wyszukiwania danych 
opartym strukturę btree. Sorry.


> Zwykle złożoność określa się czy on ma stałą złozoność (niezależną od ilości 
> danyh), liniową, wykładnicza , kwadratową , logarytmiczną itp.
W btree jest logarytmiczna przy dużej podstawie, rzędu 100-1000, zgadzamy się?


> Ale nie wynika z tego bezpośrednio ilość dostępuw do dysku.
Może zbyt skrótowo napisałem i stąd to zamieszanie.



> Obecnie wydaje mi się żaden dysk nie pracuje z zasdy pszez pobieranie 
> pojednyńczego bajtu do pamęci operacyjnej lub rejestru, a pobiera całą 
> stronę, czyli ciąg danyh, a tam może być wiele danyh akurat niebędnyh do 
> wykonania obliczeń.
Tak, właśnie ten fakt wykorzystują btree i hash-table zaprojektowane 
specjalnie z myślą o takich cechach dysku.

Weźmy zapytanie z podzapytaniem:
select *, (select * from T2) from T1; 
Jeśli system baz danych użyje btree, to dla każdego rekordu z T1 musi
pesymistycznie zrobić 4-5 dostępów dla T2. Optymalna ilość dostępów do
danych to oczywiście 1 dostęp. Zatem zapytanie to w normalnych warunkach
można zoptymalizować tylko 4-5 razy. Ktoś pisze jednak, że można 
zoptymalizować setki razy. 

Ja pytam z czego wynikają te setki razy, bo przecież trzeba mieć tabelę
zawierającą 500^100 rekordów, aby przyspieszenie 'setki razy' było w
ogóle możliwe. W jakim miejscu bazy robią taki narzut? 

Pozdrawiam




> 
> 
> -- 
> _____http://ortografia.ma7.eu_____zmiana adresu strony
> w zakładce 'inne', nowa wersja syntezatora mowy GdakMini2_99 ,
> z nowym głosem
> (tekst bez: ó, ch, rz i -ii) Ortografia to NAWYK, często nielogiczny,
> ktury ludzie ociężali umysłowo, nażucają bezmyślnie następnym pokoleniom.

On 16.12.2015 12:18, M.M. wrote:
> Ja pytam z czego wynikają te setki razy, bo przecież trzeba mieć tabelę
> zawierającą 500^100 rekordów, aby przyspieszenie 'setki razy' było w
> ogóle możliwe. W jakim miejscu bazy robią taki narzut?

Kiedy wreszcie przestaniesz masturbować się w tym temacie? Uczepiłeś się 
jednego sformułowania i przeżuwasz je jak koń owies. Nie zdążyłeś się 
zorientować, że dyskutujesz ze Stokrotką - grupowym trolem?

Przy wykorzystaniu "klasycznego" indeksu btree są co najmniej trzy 
dostępy do dysku (dostęp do korzenia indeksu o wysokości 1, jednego jego 
liścia + dostęp do pliku danych). Przy wykorzystaniu haszu niektóre 
silniki RDBMS wykonują tylko 1 dostęp w optymalnych warunkach bo wynik 
haszowania w pamięci bezpośrednio przekłada się na adres bloku na dysku.

Informacji nt. konkretnych implementacji szukaj w dokumentacji dla 
konkretnego silnika.

Co do przyspieszenia to wystarczy że przeczytasz pierwszy lepszy artykuł 
o SSD i porównasz typowe czasy dostępu względem dysków talerzowych. 
Mniej więcej daje to 10-12us dla SSD do 10-12ms dla talerzowych co 
przekłada się - teoretycznie - na 1000x szybszy dostęp do danych.

http://www.benchmark.pl/testy_i_recenzje/pojedynek-dysk-ssd-vs-dysk-twardy-2695/strona/8392.html

W praktyce wykorzystanie dysków w różnych technologiach wygląda trochę 
inaczej w benchmarkach: SSD - np. 84000 operacji odczytu na sekundę, 
talerzowy np. kilkaset. Rezultat kilkadziesiąt, może 1xx razy szybciej.

http://www.komputerswiat.pl/testy/sprzet/dyski-twarde/2015/07/dyski-ssd-test.aspx

JaceK

On Sat, 12 Dec 2015 22:01:30 +0100, szemrany wrote:

> select L.imie, L.Nazwisko, count(z.id) as liczba_samochodow from Ludzie L
> join zasoby z on z.id_1 = L.id
> join samochody s on s.id = z.id_2 
> group by L.imie, L.nazwisko
>  
> Tylko dzięki takiej budowie zapytania (w przeciwieństwie do Twojego)
> zyskujesz potwornie na wydajności. 

Chodziło mi o to, że każdy kolejny JOIN eliminuje przetwarzane rekordy i
zawęża zbiór przetwarzanych danych, tym samym ogranicza liczbę odczytów z
pliku. Złączenie dwóch tabel po kluczu obcym da w wyniku zbiór o
liczebności nie większej niż większa z tabel, w praktyce zazwyczaj
mniejszy.
Z kolei zapytanie typu scalar subquery, czyli:

select 
Pole1, 
(select PoleTB from TabelaB) as Pole2,
(select PoleTC from TabelaC) as Pole3
from TabelaA

powoduje, że dla każdego rekordu TabeliA przeczesujemy wielokrotnie całą
TabelęB, TabelęC etc. tym samym nie redukując liczby odczytów danych.

Wszystko oczywiście w jakiejś mierze redukują optymalizatory, cache,
indeksy, szybkie dyski itd., ale jak pisałem, nie skupiałem się na sprzęcie
i implementacji algorytmów tylko teorii złączeń.
Żeby to zweryfikować mależałoby stworzyć jakąś bazę i nasycić ją
odpowiednią dużą ilością danych, tak, żeby dało się dostrzec rosnące
różnice w czasie.

-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On Wednesday, December 16, 2015 at 1:34:49 PM UTC+1, szemrany wrote:
> Chodziło mi o to, że każdy kolejny JOIN eliminuje przetwarzane rekordy i
> zawęża zbiór przetwarzanych danych, tym samym ogranicza liczbę odczytów z
> pliku. 
Ok, a jakie z kolei jest tego uzasadnienie? Moim zdaniem operacje wykonywane w
joinie wymagają takiego samego przetworzenia jak w podzapytaniu.


> Złączenie dwóch tabel po kluczu obcym da w wyniku zbiór o
> liczebności nie większej niż większa z tabel, w praktyce zazwyczaj
> mniejszy.
> Z kolei zapytanie typu scalar subquery, czyli:
> 
> select 
> Pole1, 
> (select PoleTB from TabelaB) as Pole2,
> (select PoleTC from TabelaC) as Pole3
> from TabelaA
> 
> powoduje, że dla każdego rekordu TabeliA przeczesujemy wielokrotnie całą
> TabelęB, TabelęC etc. tym samym nie redukując liczby odczytów danych.
Moim zdaniem dla każdego rekordu z TabelaA przeszukamy tylko jeden raz 
TableaB i TabelaC, a jeśli TabelaB i TabelaC mają założone jakieś indeksy, to
nie będą przeszukane całe.


> Wszystko oczywiście w jakiejś mierze redukują optymalizatory, cache,
> indeksy, szybkie dyski itd., ale jak pisałem, nie skupiałem się na sprzęcie
> i implementacji algorytmów tylko teorii złączeń.
Właśnie bym chciał się dowiedzieć o co chodzi w tej teorii.


> Żeby to zweryfikować mależałoby stworzyć jakąś bazę i nasycić ją
> odpowiednią dużą ilością danych, tak, żeby dało się dostrzec rosnące
> różnice w czasie.
W moich doświadczeniach bywało rożnie, nie zawsze zapytanie z join działało
szybciej.


Pozdrawiam

On Wednesday, December 16, 2015 at 8:36:45 AM UTC-5, M.M. wrote:
> On Wednesday, December 16, 2015 at 1:34:49 PM UTC+1, szemrany wrote:
> > Chodziło mi o to, że każdy kolejny JOIN eliminuje przetwarzane rekordy i
> > zawęża zbiór przetwarzanych danych, tym samym ogranicza liczbę odczytów z
> > pliku. 
> Ok, a jakie z kolei jest tego uzasadnienie? Moim zdaniem operacje wykonywane w
> joinie wymagają takiego samego przetworzenia jak w podzapytaniu.
> 
> 
> > Złączenie dwóch tabel po kluczu obcym da w wyniku zbiór o
> > liczebności nie większej niż większa z tabel, w praktyce zazwyczaj
> > mniejszy.
> > Z kolei zapytanie typu scalar subquery, czyli:
> > 
> > select 
> > Pole1, 
> > (select PoleTB from TabelaB) as Pole2,
> > (select PoleTC from TabelaC) as Pole3
> > from TabelaA
> > 
> > powoduje, że dla każdego rekordu TabeliA przeczesujemy wielokrotnie całą
> > TabelęB, TabelęC etc. tym samym nie redukując liczby odczytów danych.
> Moim zdaniem dla każdego rekordu z TabelaA przeszukamy tylko jeden raz 
> TableaB i TabelaC, a jeśli TabelaB i TabelaC mają założone jakieś indeksy, to
> nie będą przeszukane całe.
> 
> 
> > Wszystko oczywiście w jakiejś mierze redukują optymalizatory, cache,
> > indeksy, szybkie dyski itd., ale jak pisałem, nie skupiałem się na sprzęcie
> > i implementacji algorytmów tylko teorii złączeń.
> Właśnie bym chciał się dowiedzieć o co chodzi w tej teorii.
> 
> 
> > Żeby to zweryfikować mależałoby stworzyć jakąś bazę i nasycić ją
> > odpowiednią dużą ilością danych, tak, żeby dało się dostrzec rosnące
> > różnice w czasie.
> W moich doświadczeniach bywało rożnie, nie zawsze zapytanie z join działało
> szybciej.
> 
> 
> Pozdrawiam

Dla wielu silnikow baz danych JOIN to tylko syntax sugar parser annalizuje zaptytania i niezaleznie czy sa uzyte JOINS czy wszystko jest zrobione w WHERE potrafi wygenerowac poprawne drzewo zaptyan. Niektore parsery/analizatory wystarczajaco sprytne aby jeszcze podzielic zapytania na oddzielne watki aby wykonac je jednoczesnie.
Ale i tak w wiekszoscie przypadkow wszystko zalezy od czlowieka ktory tworzy zapytanie. Idiota zrobi idiotyczne pytanie i zrobi 100% peg na procesorze i dysku. Madry czlowiek uzye explain aby zobaczyc jak zapytanie transluje sie na indeksy i klucze i zoptymalizuje je. 
Chyba ze ktos zaklada ze silnik bazy danych to system AI i nie ma znaczenia jak idiotyczne pytanie jest zadane bo zostanie ono skorygowane - wishful thinking :-(

On Wednesday, December 16, 2015 at 2:54:07 PM UTC+1, Adam M wrote:
> Dla wielu silnikow baz danych JOIN to tylko syntax sugar parser annalizuje zaptytania i niezaleznie czy sa uzyte JOINS czy wszystko jest zrobione w WHERE potrafi wygenerowac poprawne drzewo zaptyan. 

Tak samo uważam.
Pozdrawiam

On Wed, 16 Dec 2015 05:36:44 -0800 (PST), M.M. wrote:

>> Chodziło mi o to, że każdy kolejny JOIN eliminuje przetwarzane rekordy i
>> zawęża zbiór przetwarzanych danych, tym samym ogranicza liczbę odczytów z
>> pliku. 
> Ok, a jakie z kolei jest tego uzasadnienie? Moim zdaniem operacje wykonywane w
> joinie wymagają takiego samego przetworzenia jak w podzapytaniu.

Się wpakowałem z tym "setki razy" i teraz mnie do tablicy wzywasz każąc
odpowiadać na trudne pytania ;-)

http://stackoverflow.com/questions/1788678/sql-sub-query-or-inner-join

To nie jest wyjaśnienie szczegółowe, ale o to samo mi chodzi. 
Szukam ciągle potwierdzenia jakiegoś bardziej "naukowego", ale póki co nie
znalazłem nic na tyle wiarygodnego by było niepodważalne.
 

-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On Wednesday, December 16, 2015 at 4:37:05 PM UTC+1, szemrany wrote:
> On Wed, 16 Dec 2015 05:36:44 -0800 (PST), M.M. wrote:
> 
> >> Chodziło mi o to, że każdy kolejny JOIN eliminuje przetwarzane rekordy i
> >> zawęża zbiór przetwarzanych danych, tym samym ogranicza liczbę odczytów z
> >> pliku. 
> > Ok, a jakie z kolei jest tego uzasadnienie? Moim zdaniem operacje wykonywane w
> > joinie wymagają takiego samego przetworzenia jak w podzapytaniu.
> 
> Się wpakowałem z tym "setki razy" i teraz mnie do tablicy wzywasz każąc
> odpowiadać na trudne pytania ;-)
Spokojnie, ja tylko chcę się dowiedzieć. Kiedyś ktoś mi powiedział 
tak samo i uwierzyłem na słowo. Potem w praktyce było różnie. Pomyślałem że
może znasz uzasadnienie. Może to działa w jakiś szczególnych warunkach... 
Jeśli nie znasz uzasadnienia, to rozumiem, nie będę dopytywał.



> http://stackoverflow.com/questions/1788678/sql-sub-query-or-inner-join
> 
> To nie jest wyjaśnienie szczegółowe, ale o to samo mi chodzi. 
> Szukam ciągle potwierdzenia jakiegoś bardziej "naukowego", ale póki co nie
> znalazłem nic na tyle wiarygodnego by było niepodważalne.

Hmmm może to jest mit?

Pozdrawiam

On Wed, 16 Dec 2015 07:43:51 -0800 (PST), M.M. wrote:

>>> Ok, a jakie z kolei jest tego uzasadnienie? Moim zdaniem operacje wykonywane w
>>> joinie wymagają takiego samego przetworzenia jak w podzapytaniu.
>> 
>> Się wpakowałem z tym "setki razy" i teraz mnie do tablicy wzywasz każąc
>> odpowiadać na trudne pytania ;-)
> Spokojnie, ja tylko chcę się dowiedzieć. Kiedyś ktoś mi powiedział 
> tak samo i uwierzyłem na słowo. Potem w praktyce było różnie. Pomyślałem że
> może znasz uzasadnienie. Może to działa w jakiś szczególnych warunkach... 
> Jeśli nie znasz uzasadnienia, to rozumiem, nie będę dopytywał.

http://www.sqlservice.se/sql-server-performance-death-by-correlated-subqueries/


-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On Wed, 16 Dec 2015 07:43:51 -0800 (PST), M.M. wrote:

> On Wednesday, December 16, 2015 at 4:37:05 PM UTC+1, szemrany wrote:
>> On Wed, 16 Dec 2015 05:36:44 -0800 (PST), M.M. wrote:
>> 
>>>> Chodziło mi o to, że każdy kolejny JOIN eliminuje przetwarzane rekordy i
>>>> zawęża zbiór przetwarzanych danych, tym samym ogranicza liczbę odczytów z
>>>> pliku. 
>>> Ok, a jakie z kolei jest tego uzasadnienie? Moim zdaniem operacje wykonywane w
>>> joinie wymagają takiego samego przetworzenia jak w podzapytaniu.
>> 
>> Się wpakowałem z tym "setki razy" i teraz mnie do tablicy wzywasz każąc
>> odpowiadać na trudne pytania ;-)
> Spokojnie, ja tylko chcę się dowiedzieć. Kiedyś ktoś mi powiedział 
> tak samo i uwierzyłem na słowo. Potem w praktyce było różnie. Pomyślałem że
> może znasz uzasadnienie. Może to działa w jakiś szczególnych warunkach... 
> Jeśli nie znasz uzasadnienia, to rozumiem, nie będę dopytywał.
> 
> 
> 
>> http://stackoverflow.com/questions/1788678/sql-sub-query-or-inner-join
>> 
>> To nie jest wyjaśnienie szczegółowe, ale o to samo mi chodzi. 
>> Szukam ciągle potwierdzenia jakiegoś bardziej "naukowego", ale póki co nie
>> znalazłem nic na tyle wiarygodnego by było niepodważalne.
> 
> Hmmm może to jest mit?

No to się poświęciłem i zamiast zajmować się pracą robiłem testy, oto
wyniki "badań" przeprowadzonych na serwerze Firebird 2.5:

http://snap.ashampoo.com/uploads/2015-12-17/ns9NcBYp.png

Po lewej Twoja wersja zapytania, po prawej z joinami.

A to realne odczyty wykonane przez serwer:

http://snap.ashampoo.com/uploads/2015-12-17/IQiC574j.png


-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On Thursday, December 17, 2015 at 9:25:07 AM UTC-5, szemrany wrote:
> On Wed, 16 Dec 2015 07:43:51 -0800 (PST), M.M. wrote:
> 
> > On Wednesday, December 16, 2015 at 4:37:05 PM UTC+1, szemrany wrote:
> >> On Wed, 16 Dec 2015 05:36:44 -0800 (PST), M.M. wrote:
> >> 
> >>>> Chodziło mi o to, że każdy kolejny JOIN eliminuje przetwarzane rekordy i
> >>>> zawęża zbiór przetwarzanych danych, tym samym ogranicza liczbę odczytów z
> >>>> pliku. 
> >>> Ok, a jakie z kolei jest tego uzasadnienie? Moim zdaniem operacje wykonywane w
> >>> joinie wymagają takiego samego przetworzenia jak w podzapytaniu.
> >> 
> >> Się wpakowałem z tym "setki razy" i teraz mnie do tablicy wzywasz każąc
> >> odpowiadać na trudne pytania ;-)
> > Spokojnie, ja tylko chcę się dowiedzieć. Kiedyś ktoś mi powiedział 
> > tak samo i uwierzyłem na słowo. Potem w praktyce było różnie. Pomyślałem że
> > może znasz uzasadnienie. Może to działa w jakiś szczególnych warunkach... 
> > Jeśli nie znasz uzasadnienia, to rozumiem, nie będę dopytywał.
> > 
> > 
> > 
> >> http://stackoverflow.com/questions/1788678/sql-sub-query-or-inner-join
> >> 
> >> To nie jest wyjaśnienie szczegółowe, ale o to samo mi chodzi. 
> >> Szukam ciągle potwierdzenia jakiegoś bardziej "naukowego", ale póki co nie
> >> znalazłem nic na tyle wiarygodnego by było niepodważalne.
> > 
> > Hmmm może to jest mit?
> 
> No to się poświęciłem i zamiast zajmować się pracą robiłem testy, oto
> wyniki "badań" przeprowadzonych na serwerze Firebird 2.5:
> 
> http://snap.ashampoo.com/uploads/2015-12-17/ns9NcBYp.png
> 
> Po lewej Twoja wersja zapytania, po prawej z joinami.
> 
> A to realne odczyty wykonane przez serwer:
> 
> http://snap.ashampoo.com/uploads/2015-12-17/IQiC574j.png
> 
> 
> -- 
> howgh
> szemrany
> "Trzeba z żywymi naprzód iść, po życie sięgać nowe,
> a nie w uwiędłych laurów liść z uporem stroić głowę"

No i dzieki poswieceniu kolegi dowiedzielismy sie ze idiotyczne zapytanie zabije serwer (prosze nie traktowac tego jako osobista wycieczke - kolega po prostu sprawdzil ze "garbage in -> garbage out").
Juz na pierwszy rzut oka widac ze pierwsze zapytanie bedzie sie wykonywalo w niesamowicie dlugi sposob dzieki full scan na tabelach - do tego nawet nie potrzeba analizowac planu wykonania.

On Thu, 17 Dec 2015 06:37:58 -0800 (PST), Adam M wrote:

>> No to się poświęciłem i zamiast zajmować się pracą robiłem testy, oto
>> wyniki "badań" przeprowadzonych na serwerze Firebird 2.5:
>> 
>> http://snap.ashampoo.com/uploads/2015-12-17/ns9NcBYp.png
>> 
>> Po lewej Twoja wersja zapytania, po prawej z joinami.
>> 
>> A to realne odczyty wykonane przez serwer:
>> 
>> http://snap.ashampoo.com/uploads/2015-12-17/IQiC574j.png
> 
> No i dzieki poswieceniu kolegi dowiedzielismy sie ze idiotyczne zapytanie zabije serwer (prosze nie traktowac tego jako osobista wycieczke - kolega po prostu sprawdzil ze "garbage in -> garbage out").
> Juz na pierwszy rzut oka widac ze pierwsze zapytanie bedzie sie wykonywalo w niesamowicie dlugi sposob dzieki full scan na tabelach - do tego nawet nie potrzeba analizowac planu wykonania.

Ale o to właśnie trwa dyskurs od kilku dni, nie było dotąd żadnego
potwierdzenia i padło podejrzenie mitologii  :-)

-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On 17.12.2015 15:25, szemrany wrote:
> No to się poświęciłem i zamiast zajmować się pracą robiłem testy, oto
> wyniki "badań" przeprowadzonych na serwerze Firebird 2.5:
>
> http://snap.ashampoo.com/uploads/2015-12-17/ns9NcBYp.png
>
> Po lewej Twoja wersja zapytania, po prawej z joinami.
>
> A to realne odczyty wykonane przez serwer:
>
> http://snap.ashampoo.com/uploads/2015-12-17/IQiC574j.png

I wyniki są takie same?

Po lewej wybierasz wszystkie idautko z A i dla tych idautko obliczasz 
count(*) w R. Ponieważ nie ma połączenia z tabelą osoba to 
prawdopodobnie uzyskujesz takie same wartości count(*) dla każdej osoby.

Po prawej obliczasz count(*) tylko dla pasujących po idosoba oraz 
idautko/idxxx, i grupowanie zlicza odpowiednio wystąpienia w R dla 
każdej osoby z osobna.

Jak na mój gust to zgubiłeś jedno złączenie w zapytaniu po lewej ale 
cholera wie, może mam zaćmienie bo nie spałem. Sprawdź to:

select o.nazwisko,
( select count(*)
   from rel_xxx r
   join autko a on a.idautko = r.idxxx
   where r.idosoba = o.idosoba ) as liczba_pojazdow
from osoba o
where o.idosoba < 11;

JaceK

W dniu 2015-12-17 o 15:25, szemrany pisze:
> No to się poświęciłem i zamiast zajmować się pracą robiłem testy,
> oto wyniki "badań" przeprowadzonych na serwerze Firebird 2.5:
>
> http://snap.ashampoo.com/uploads/2015-12-17/ns9NcBYp.png
>
> Po lewej Twoja wersja zapytania, po prawej z joinami.
>
> A to realne odczyty wykonane przez serwer:
>
> http://snap.ashampoo.com/uploads/2015-12-17/IQiC574j.png

Do tej pory w tej dyskusji nigdzie chyba nie napisałeś, że odnosisz 
swoje rozważania do Firebirda. A optymalizator Firebirda nie jest 
najwyższych lotów i to co być może Oracle czy MSSQL wykonał by 
efektywniej tutaj wygląda kiepsko.
Za to skutecznie oducza od "dziwnych" konstrukcji takich jak zapytanie 
nr 1 i przyzwyczaja do pisania zapytań zgodnie z podstawowymi regułami 
(stosowanie join i cte).

Tomek D.

On Thursday, December 17, 2015 at 9:41:56 AM UTC-5, szemrany wrote:
> On Thu, 17 Dec 2015 06:37:58 -0800 (PST), Adam M wrote:
> 
> >> No to się poświęciłem i zamiast zajmować się pracą robiłem testy, oto
> >> wyniki "badań" przeprowadzonych na serwerze Firebird 2.5:
> >> 
> >> http://snap.ashampoo.com/uploads/2015-12-17/ns9NcBYp.png
> >> 
> >> Po lewej Twoja wersja zapytania, po prawej z joinami.
> >> 
> >> A to realne odczyty wykonane przez serwer:
> >> 
> >> http://snap.ashampoo.com/uploads/2015-12-17/IQiC574j.png
> > 
> > No i dzieki poswieceniu kolegi dowiedzielismy sie ze idiotyczne zapytanie zabije serwer (prosze nie traktowac tego jako osobista wycieczke - kolega po prostu sprawdzil ze "garbage in -> garbage out").
> > Juz na pierwszy rzut oka widac ze pierwsze zapytanie bedzie sie wykonywalo w niesamowicie dlugi sposob dzieki full scan na tabelach - do tego nawet nie potrzeba analizowac planu wykonania.
> 
> Ale o to właśnie trwa dyskurs od kilku dni, nie było dotąd żadnego
> potwierdzenia i padło podejrzenie mitologii  :-)
> 
> -- 
> howgh
> szemrany
> "Trzeba z żywymi naprzód iść, po życie sięgać nowe,
> a nie w uwiędłych laurów liść z uporem stroić głowę"

Jak juz napisalem wczoraj ten watek to "dyskusja dziesieciu slepych o tym jak wyglada slon" lub bardziej wulgarnie "dyskusja jebakow teoretykow na temat kondonow"
- jeszcze raz przepraszam za wulgaryzmy ;-D

On Thursday, December 17, 2015 at 3:47:05 PM UTC+1, Tomek D wrote:
> W dniu 2015-12-17 o 15:25, szemrany pisze:
> > No to się poświęciłem i zamiast zajmować się pracą robiłem testy,
> > oto wyniki "badań" przeprowadzonych na serwerze Firebird 2.5:
> >
> > http://snap.ashampoo.com/uploads/2015-12-17/ns9NcBYp.png
> >
> > Po lewej Twoja wersja zapytania, po prawej z joinami.
> >
> > A to realne odczyty wykonane przez serwer:
> >
> > http://snap.ashampoo.com/uploads/2015-12-17/IQiC574j.png
> 
> Do tej pory w tej dyskusji nigdzie chyba nie napisałeś, że odnosisz 
> swoje rozważania do Firebirda. A optymalizator Firebirda nie jest 
> najwyższych lotów i to co być może Oracle czy MSSQL wykonał by 
> efektywniej tutaj wygląda kiepsko.
> Za to skutecznie oducza od "dziwnych" konstrukcji takich jak zapytanie 
> nr 1 i przyzwyczaja do pisania zapytań zgodnie z podstawowymi regułami 
> (stosowanie join i cte).
> 
> Tomek D.

Może mamy uzasadnienie: Więcej silników umie zoptymalizować JOIN niż 
podzapytanie.

On Thursday, December 17, 2015 at 3:25:07 PM UTC+1, szemrany wrote:
> On Wed, 16 Dec 2015 07:43:51 -0800 (PST), M.M. wrote:
> 
> > On Wednesday, December 16, 2015 at 4:37:05 PM UTC+1, szemrany wrote:
> >> On Wed, 16 Dec 2015 05:36:44 -0800 (PST), M.M. wrote:
> >> 
> >>>> Chodziło mi o to, że każdy kolejny JOIN eliminuje przetwarzane rekordy i
> >>>> zawęża zbiór przetwarzanych danych, tym samym ogranicza liczbę odczytów z
> >>>> pliku. 
> >>> Ok, a jakie z kolei jest tego uzasadnienie? Moim zdaniem operacje wykonywane w
> >>> joinie wymagają takiego samego przetworzenia jak w podzapytaniu.
> >> 
> >> Się wpakowałem z tym "setki razy" i teraz mnie do tablicy wzywasz każąc
> >> odpowiadać na trudne pytania ;-)
> > Spokojnie, ja tylko chcę się dowiedzieć. Kiedyś ktoś mi powiedział 
> > tak samo i uwierzyłem na słowo. Potem w praktyce było różnie. Pomyślałem że
> > może znasz uzasadnienie. Może to działa w jakiś szczególnych warunkach... 
> > Jeśli nie znasz uzasadnienia, to rozumiem, nie będę dopytywał.
> > 
> > 
> > 
> >> http://stackoverflow.com/questions/1788678/sql-sub-query-or-inner-join
> >> 
> >> To nie jest wyjaśnienie szczegółowe, ale o to samo mi chodzi. 
> >> Szukam ciągle potwierdzenia jakiegoś bardziej "naukowego", ale póki co nie
> >> znalazłem nic na tyle wiarygodnego by było niepodważalne.
> > 
> > Hmmm może to jest mit?
> 
> No to się poświęciłem i zamiast zajmować się pracą robiłem testy, oto
> wyniki "badań" przeprowadzonych na serwerze Firebird 2.5:
Dziękuję uprzejmie :) Trochę mi głupio, że aż tak Cię zaabsorbowałem.

Nie mamy teorii, ale za to mamy doświadczenie praktyczne. Dobrze. To
ja może też zrobię. Ale (jeśli w ogóle zrobię) to w C++. Potem co
bardziej doświadczeni wskażą co poprawić, co warto dodać, etc. W
końcu odpalimy na różnych silnikach, na różnym sprzęcie, na różnych 
rozmiarach tabel, etc.



> 
> http://snap.ashampoo.com/uploads/2015-12-17/ns9NcBYp.png
> 
> Po lewej Twoja wersja zapytania, po prawej z joinami.
> 
> A to realne odczyty wykonane przez serwer:
> 
> http://snap.ashampoo.com/uploads/2015-12-17/IQiC574j.png

Masz milion osób i 540tys aut. Czas z podzapytaniem 1m i 46s.
Czas z group by 15ms. Szok. Zobaczymy jak podobny test
wypadnie w postgresie. 

Pozdrawiam




> 
> 
> -- 
> howgh
> szemrany
> "Trzeba z żywymi naprzód iść, po życie sięgać nowe,
> a nie w uwiędłych laurów liść z uporem stroić głowę"

On Thursday, December 17, 2015 at 3:47:36 PM UTC+1, Adam M wrote:
> On Thursday, December 17, 2015 at 9:41:56 AM UTC-5, szemrany wrote:
> > On Thu, 17 Dec 2015 06:37:58 -0800 (PST), Adam M wrote:
> > 
> > >> No to się poświęciłem i zamiast zajmować się pracą robiłem testy, oto
> > >> wyniki "badań" przeprowadzonych na serwerze Firebird 2.5:
> > >> 
> > >> http://snap.ashampoo.com/uploads/2015-12-17/ns9NcBYp.png
> > >> 
> > >> Po lewej Twoja wersja zapytania, po prawej z joinami.
> > >> 
> > >> A to realne odczyty wykonane przez serwer:
> > >> 
> > >> http://snap.ashampoo.com/uploads/2015-12-17/IQiC574j.png
> > > 
> > > No i dzieki poswieceniu kolegi dowiedzielismy sie ze idiotyczne zapytanie zabije serwer (prosze nie traktowac tego jako osobista wycieczke - kolega po prostu sprawdzil ze "garbage in -> garbage out").
> > > Juz na pierwszy rzut oka widac ze pierwsze zapytanie bedzie sie wykonywalo w niesamowicie dlugi sposob dzieki full scan na tabelach - do tego nawet nie potrzeba analizowac planu wykonania.
> > 
> > Ale o to właśnie trwa dyskurs od kilku dni, nie było dotąd żadnego
> > potwierdzenia i padło podejrzenie mitologii  :-)
> > 
> > -- 
> > howgh
> > szemrany
> > "Trzeba z żywymi naprzód iść, po życie sięgać nowe,
> > a nie w uwiędłych laurów liść z uporem stroić głowę"
> 
> Jak juz napisalem wczoraj ten watek to "dyskusja dziesieciu slepych o tym jak wyglada slon" lub bardziej wulgarnie "dyskusja jebakow teoretykow na temat kondonow"
> - jeszcze raz przepraszam za wulgaryzmy ;-D

My wiemy że na razie pominęliśmy tak dużo szczegółów, że rozmowa przypomina
rozmowę ślepców, ale idzie w dobrym kierunku. Będziesz miał okazję dorzucić
swoją profesjonalną korektę :)

On Thu, 17 Dec 2015 07:28:34 -0800 (PST), M.M. wrote:

>> No to się poświęciłem i zamiast zajmować się pracą robiłem testy, oto
>> wyniki "badań" przeprowadzonych na serwerze Firebird 2.5:
> Dziękuję uprzejmie :) Trochę mi głupio, że aż tak Cię zaabsorbowałem.
> 
> Nie mamy teorii, ale za to mamy doświadczenie praktyczne. Dobrze. To
> ja może też zrobię. Ale (jeśli w ogóle zrobię) to w C++. Potem co
> bardziej doświadczeni wskażą co poprawić, co warto dodać, etc. W
> końcu odpalimy na różnych silnikach, na różnym sprzęcie, na różnych 
> rozmiarach tabel, etc.

Stop...!
Fakin szit... zrobiłem błąd, który słusznie zauważył JaceK. Zrobiłem go
dlatego, że mieszałem z zapytaniami wiele godzin kombinując z różnymi
opcjami, różnymi wielościami danych, różnymi warunkami, udziałem większej
liczby kolumn i tabel etc.
Gdy uwzględnię warunek jaki pominąłem to wynik Twojego subquery jest
identyczny jak tego z joinami, zatem... wyszło, żem bredził, za co muszę
przeprosić. Ale przy okazji stwierdzam, że jestem w szoku.

http://snap.ashampoo.com/uploads/2015-12-17/xwGrGnZv.png

Powiem tylko na obronę, że jak już ktoś wspomniał, Firebird nie słynie z
mocy optymalizatora, a moje przekonanie o tym, że subquery jest ewidentnie
słabsze bazuje na doświadczeniach i eksperymentach sprzed lat, które były
robione także na Firebirdzie (i MySQLu), ale wersjach z tamtych lat.
Widocznie chłopaki odrobili zadanie domowe i FB optymalizator w FB stał się
smart :-)

-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On 17.12.2015 17:43, szemrany wrote:
> Powiem tylko na obronę, że jak już ktoś wspomniał, Firebird nie słynie z
> mocy optymalizatora, a moje przekonanie o tym, że subquery jest ewidentnie
> słabsze bazuje na doświadczeniach i eksperymentach sprzed lat, które były
> robione także na Firebirdzie (i MySQLu), ale wersjach z tamtych lat.
> Widocznie chłopaki odrobili zadanie domowe i FB optymalizator w FB stał się
> smart :-)

Jak już zauważył kolega amorawski JOIN to tylko składnia. W jaki sposób 
zapytanie SQL zostanie wykonane to już zależy od bebechów silnika. Aby 
nie trzymać Cię w niepewności powiem, że twoje przekonanie jest 
częściowo słuszne gdyż np. podzapytania skorelowane, mogą - ale nie 
muszą - obniżać wydajność. Dzieje się tak wtedy, gdy duża tabela jest 
wielokrotnie odczytywana w całości, dla każdego rekordu z tabeli 
"sterującej". To, czy zapytanie zostanie jednak wykonane jako 
skorelowane zależy od bebechów silnika, na które częściowo można wpływać 
np. hintami. Dlatego dobrze jest rozumieć podstawowe mechanizmy dostępu 
do danych i przyglądać się planom wykonania. Bo jak już zauważył kolega 
amorawski JOIN to tylko składnia...

JaceK

On Thursday, December 17, 2015 at 5:43:10 PM UTC+1, szemrany wrote:
> On Thu, 17 Dec 2015 07:28:34 -0800 (PST), M.M. wrote:
> 
> >> No to się poświęciłem i zamiast zajmować się pracą robiłem testy, oto
> >> wyniki "badań" przeprowadzonych na serwerze Firebird 2.5:
> > Dziękuję uprzejmie :) Trochę mi głupio, że aż tak Cię zaabsorbowałem.
> > 
> > Nie mamy teorii, ale za to mamy doświadczenie praktyczne. Dobrze. To
> > ja może też zrobię. Ale (jeśli w ogóle zrobię) to w C++. Potem co
> > bardziej doświadczeni wskażą co poprawić, co warto dodać, etc. W
> > końcu odpalimy na różnych silnikach, na różnym sprzęcie, na różnych 
> > rozmiarach tabel, etc.
> 
> Stop...!
> Fakin szit... zrobiłem błąd, który słusznie zauważył JaceK.

Nie martw się, w pośpiechu tak to jest. Mój program na razie
też nie przechodzi asercji, a już nie mam czasu. Jak ktoś chce, 
niech dokończy/poprawi. Ja może za jakiś czas do tego wrócę.

http://pastebin.com/K3gMmXWG


Pozdrawiam

On Thursday, December 17, 2015 at 5:43:10 PM UTC+1, szemrany wrote:
> On Thu, 17 Dec 2015 07:28:34 -0800 (PST), M.M. wrote:
> 
> >> No to się poświęciłem i zamiast zajmować się pracą robiłem testy, oto
> >> wyniki "badań" przeprowadzonych na serwerze Firebird 2.5:
> > Dziękuję uprzejmie :) Trochę mi głupio, że aż tak Cię zaabsorbowałem.
> > 
> > Nie mamy teorii, ale za to mamy doświadczenie praktyczne. Dobrze. To
> > ja może też zrobię. Ale (jeśli w ogóle zrobię) to w C++. Potem co
> > bardziej doświadczeni wskażą co poprawić, co warto dodać, etc. W
> > końcu odpalimy na różnych silnikach, na różnym sprzęcie, na różnych 
> > rozmiarach tabel, etc.
> 
> Stop...!
Przepraszam że odpowiadam na raty. U mnie dopiero takie zapytanie
daje ten sam zbiór rekordów:

select   
  p.id,   
  p.name,   
  p.surename,   
  p.age,   
  sum( case when c1.id2 is null then 0 else 1 end ) as amount_cars  
from  
  persons as p  
left join  
  conn1 as c1  
on  
  c1.id2 = p.id  
group by    
  p.id,   
  p.name,   
  p.surename,   
  p.age ;

Pozdrawiam

On Thursday, December 17, 2015 at 5:43:10 PM UTC+1, szemrany wrote:
> On Thu, 17 Dec 2015 07:28:34 -0800 (PST), M.M. wrote:
> 
> >> No to się poświęciłem i zamiast zajmować się pracą robiłem testy, oto
> >> wyniki "badań" przeprowadzonych na serwerze Firebird 2.5:
> > Dziękuję uprzejmie :) Trochę mi głupio, że aż tak Cię zaabsorbowałem.
> > 
> > Nie mamy teorii, ale za to mamy doświadczenie praktyczne. Dobrze. To
> > ja może też zrobię. Ale (jeśli w ogóle zrobię) to w C++. Potem co
> > bardziej doświadczeni wskażą co poprawić, co warto dodać, etc. W
> > końcu odpalimy na różnych silnikach, na różnym sprzęcie, na różnych 
> > rozmiarach tabel, etc.
> 
> Stop...!
Kontynuując....

Wynik testu:


insertCars      235ms
insertPers      348ms
idCars       17ms (10000)
idPers       17ms (10000)
carsToPersons     1768ms (75386)
test_01   102767ms (1053792664) (10000)  // test_01 to podzapytanie
test_02     1395ms (1053792664) (10000)  // test_02 to group by
test_01   102748ms (1053792664) (10000)
test_02     1391ms (1053792664) (10000)
cidxConn1Id2Btree      192ms               // create index btree
test_01      364ms (1053792664) (10000)
test_02     1390ms (1053792664) (10000)
test_01      361ms (1053792664) (10000)
test_02     1388ms (1053792664) (10000)
didxConn1Id2Btree       15ms               // delete index btree
cidxConn1Id2Hash      110ms                // create index hash
test_01      382ms (1053792664) (10000)
test_02     1388ms (1053792664) (10000)
test_01      382ms (1053792664) (10000)
test_02     1389ms (1053792664) (10000)
didxConn1Id2Hash       24ms                // delete index hash
test_01   102695ms (1053792664) (10000)
test_02     1393ms (1053792664) (10000)
test_01   102805ms (1053792664) (10000)
test_02     1389ms (1053792664) (10000)

Wersja z podzapytaniem:
select  
  p.id,  
  p.name,  
  p.surename,  
  p.age,  
  (select count(*) from conn1 where id2=p.id) as amount_cars 
from 
  persons as p ;


Wersja z group by:
select   
  p.id,   
  p.name,   
  p.surename,   
  p.age,   
  sum( case when c1.id2 is null then 0 else 1 end ) as amount_cars  
from  
  persons as p  
left join  
  conn1 as c1  
on  
  c1.id2 = p.id  
group by    
  p.id,   
  p.name,   
  p.surename,   
  p.age ;

Baza: postgres 9.3.9
Sprzęt: jak ktoś zainteresowany to potem dołączę, na pewno cała baza
mieściła się w RAM.

Wnioski:
Bez indeksów gropu by działa 100 razy szybciej (na tym przykładzie,
rzecz jasna). Z indeksami group by działa 3-4 razy wolniej. Czy index
hash, czy btree - nie było różnicy. Jeszcze jeden wniosek: z join 
trudniej napisać zapytanie, obaj się pomyliliśmy, a Ci co oglądali wynik
też nie rzucili z rękawa poprawnego zapytania.

Źródło całego testu:
http://pastebin.com/X9yGCfZr

Pozdrawiam

On Thursday, December 17, 2015 at 9:15:18 PM UTC+1, M.M. wrote:

Na wiekszym zbiorze danych ładniej widać różnicę:

Bez indeksów group by jest 130 razy szybsze.
Z indeksami btree podzapytanie jest 14 razy szybsze.

insertCars      469ms
insertPers      730ms
idCars       32ms (20000)
idPers       32ms (20000)
carsToPersons     5921ms (249377)
test_01   674207ms (0) (20000)
test_02     5165ms (0) (20000)
test_01   673290ms (0) (20000)
test_02     5167ms (0) (20000)
cidxConn1Id2Btree      399ms 
test_01      380ms (0) (20000)
test_02     5162ms (0) (20000)
test_01      371ms (0) (20000)
test_02     5164ms (0) (20000)
didxConn1Id2Btree       24ms 
cidxConn1Id2Hash      375ms 
test_01      425ms (0) (20000)
test_02     5170ms (0) (20000)
test_01      424ms (0) (20000)
test_02     5164ms (0) (20000)
didxConn1Id2Hash       31ms

On Fri, 18 Dec 2015 03:02:40 -0800 (PST), M.M. wrote:

> Na wiekszym zbiorze danych ładniej widać różnicę:
> 
> Bez indeksów group by jest 130 razy szybsze.
> Z indeksami btree podzapytanie jest 14 razy szybsze.

Czyli w PostgreSQL zapytanie z subquery jest 14 razy szybsze niż z JOINami?
Dobrze to rozumiem? 
Ten sam test, który w Firebirdzie dał identyczne czasy?

-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On Friday, December 18, 2015 at 12:19:35 PM UTC+1, szemrany wrote:
> On Fri, 18 Dec 2015 03:02:40 -0800 (PST), M.M. wrote:
> 
> > Na wiekszym zbiorze danych ładniej widać różnicę:
> > 
> > Bez indeksów group by jest 130 razy szybsze.
> > Z indeksami btree podzapytanie jest 14 razy szybsze.
> 
> Czyli w PostgreSQL zapytanie z subquery jest 14 razy szybsze niż z JOINami?
> Dobrze to rozumiem? 
Tak, dobrze rozumiesz, ale jeszcze trzeba coś dodać. Zapytanie z JOINami
jest tylko takie, jakie ja umiem wpisać. Dlatego dałem kod, aby ktoś
chętny mógł je zoptymalizować - o ile się da. Wystarczy zmienić zapytania,
skompilować i uruchomić program.

> Ten sam test, który w Firebirdzie dał identyczne czasy?
Nie, do tego testu jeszcze nie doszedłem. Test jest prostszy, można go
dopiero rozbudować do Twojej wersji. Obecnie test pobiera z bazy

person.id, person.name, person.surename, person.age, count(cars).

Możesz napisać kilka zapytań, to wrzucę je do programu i uruchomię
test z indeksami i bez. Są asercje, będziemy wiedzieli czy zapytania
zwracają ten sam zbiór rekordów.

Struktura bazy jest tam:
http://pastebin.com/DkywSNb3

tabela conn1 (connect 1) ma id1 i id2 - można jej użyć do złączeń.
ID własne są unikalne w obrębie całej bazy.

Jeśli kiedyś znajdę czas, to zrobię taki test na kilka silników.

Pozdrawiam

On Friday, December 18, 2015 at 12:19:35 PM UTC+1, szemrany wrote:
> Ten sam test, który w Firebirdzie dał identyczne czasy?
Wpatruję się w Twoje zapytania i dochodzę do wniosku że są prawie
takie same jak moje. Złączasz jeszcze z trzecią tabelą: 'samochody'.
Do samego zliczania to złączenie nie jest potrzebne, dlatego 
błędnie pomyślałem, że warunek w where dotyczy samochodów :)
Czyli zapytania są bardzo podobne do Twoich.


Pozdrawiam