SQL - prośba o wyjaśnienie kodów

Question

Witam,

 

mam napisane trzy raporty w SQL. W związku z tym mam prośbę o dokładne ich objaśnienie co po kolei się dzieje.

Tabele: Pracownicy, Klienci, Miejsca, Rowery, wypożyczenia

 

create view raport_nr1 as(
select top 5 Miejsca.Ulica,Miejsca.Numer, Count(Miejsca.ID) as ilosc_oddan from Miejsca
join Wypozyczenia on Miejsca.ID=Wypozyczenia.ID_miejsca_odd
group by Ulica, Numer
Order by ilosc_oddan desc
)
go

create view raport_nr2 as(
select Imie, Nazwisko, Count(*) as 'ilosc'
from Pracownicy
join Wypozyczenia on Pracownicy.ID=Wypozyczenia.ID_pracwnika_wyp
group by Imie, Nazwisko
having count(*)>5

)
go

create view raport_nr3 as(
select top 1 convert(varchar(12), Data_od, 104) as dzien,count(*) as ilosc
from Wypozyczenia
group by convert(varchar(12), Data_od, 104)
order by ilosc desc
)
go

 

Bardzo dziękuję za pomoc

Answer 1

Masz założone widoki na tabele. Dzięki temu widzisz, co się dzieje po tych select'ach, łatwiej dostrzeć i później operować na widokach aniżeli na takim wielkim/dużym jednym zapytaniu. W widoku o nazwie raport_nr1 wyciągasz dane z tabeil Miejsca oraz łączysz tabele za pomocą join'a.

Miejsca.Ulica => tabela.kolumna. Wyciągasz dane z tabeli miejsca z kolumny Ulica.

table_reference JOIN table_factor ON conditional_expr

Opinie są takie że widoki są podobno wolne i powinno się je chyba na końcu zlikwidować, czyli przepisać zapytanie bez widoków, one są tylko do podglądu, ale mogę się mylić.

 

 

 

 

Comments

Opinie są takie że widoki są podobno wolne i powinno się je chyba na końcu zlikwidować

Co rozumiesz pod pojęciem "wolne"?

Pytam, ponieważ bardzo często widzę, że ludzie stosują tego typu określenia do różnych zapytań i operacji bazodanowych bez analizy faktycznego przypadku. Sam często korzystam z widoków żeby nie wysyłać co chwilę dość rozbudowanego selecta i jest to dość wygodne rozwiązanie.

Pytanie co chcesz z tych widoków pobierać, jak często, ile masz rekordów do analizy itp. Myślę, że nie należy zbyt mocno uogólniać tez o szybkości jakiegoś rozwiązania, jeśli nie znamy problemu kompleksowo. Szczególnie, że jest to forum, z którego korzysta wielu początkujących programistów i niepotrzebnie mogą sobie wyrabiać nie zawsze prawdziwe opinie.

---

Chodzi mi o tak jakby wydajność, czy to, że zapytanie się będzie dłużej wykonywało.

https://dba.stackexchange.com/questions/16372/when-to-use-views-in-mysql

https://stackoverflow.com/questions/10302615/mysql-views-performance

---

Wszystko oki, ale ponownie powiem to samo - nie oceniajmy wydajności i optymalizacji bazy bez znajomości całej bazy i zapytań. Jeśli np. poruszamy się po tabelach zawierających kilkadziesiąt czy kilkaset rekordów to nawet prosty iloczyn kartezjański nie będzie wielkim problemem bo de facto baza MySQL jest dość szybka.

Inaczej jeśli wchodzimy w dziesiątki i setki tysięcy rekordów. W tak dużych bazach już bardzo istotną kwestią jest odpowiednie zarządzanie indeksami i ogólna optymalizacja zapytań. W dużej bazie nie wyobrażam sobie tworzenia rozbudowanego selecta bez analizy EXPLAIN.

Ponad to widoki zapewniają większe bezpieczeństwo jeśli odpowiednio się je stworzy co czasami może wygrać z wydajnością (nie przesadzajmy już z tymi mikrosekundami przy "typowych" niedużych bazach).

Jeśli faktycznie dla jakiegoś zapytania priorytetem jest wydajność i mówimy o dużej bazie to może warto zastanowić się nad silnikiem bazy (InnoDB to nie jedyny silniczek w MySQL) i innych rozwiązaniach.

Często mówi się, żeby w tabelach zakładać indeksy bo przyspieszają pracę. Owszem... ale jaki sens ma ineksowanie tabeli, na której 99,9% kwerend to INSERT (tabela zawierająca logi) czyli indeksowanie "przelatuje" dla każdej operacji INSERT? (spotkałem się z taką właśnie sytuacją i usłyszałem, że indeksy przecież znacznie przyspieszą pracę na tabeli...). Nie uogólniajmy więc stwierdzeń dotyczących wydajności, albo wprost określajmy w jakich przypadkach dane rozwiązanie jest mniej lub bardziej efektywne i co ważne... wydajność to nie zawsze priorytet, wszystko zależy od konkretnego przypadku.