Serwus Darek, w końcu znalazłem czas, aby obejrzeć Twoją lekcję. Cały czas miałem ją na liście otwartej z moim zadaniami. Teraz rozumiem czym jest CTE i powinienem go kojarzysz przede wszystkim z operacjami w hurtowniach danych. Uważam że lekcja bardzo interesująca tymbardziej, że w Internecie trudno znaleźć tak dobrze "spakowane" informacje o CTE. Pozdrawiam.
@@dariuszmion2764 w kursie omawiam każde zagadnienie na przykładzie Oracle, Sql Server i Postgres. Rozszerzanie tego na kilka kolejnych silników wydłużałoby jeszcze bardziej kurs, a tego chciałem uniknąć.
W najbliższym czasie na YT raczej nie, bo mam już przygotowanych kilka tematów na kolejne materiały. W kursie SQL promo.mistrzsql.pl/ będzie ten temat kompleksowo poruszony: CONNECT BY (NOCYCLE), START WITH, ORDER BY SIBLINGS, LEVEL, CONNECT_BY_ISCYCLE, CONNECT BY_ISLEAF, PRIOR, CONNEC_BY_ROOT oraz SYS_CONNECT_BY_PATH. Porównamy też sobie te Oraclowe rozwiązanie z RECURSIVE CTE :)
Temat na czasie dla mnie, dzisiaj przerobiłem zapytanie z CTE na tabelki tymczasowe #. Czas z 2 minut zszedł do 1 sec :D Nie wiem jakim cudem bo zapytanie nie było jakies skomplikowane.
Myślę, że ta ciągła popularność cte w Oracle jest efektem problematycznej implementacji tabel tymczasowych. Nie używałem już Oracle/pl/sqla od dłuższego czasu, ale w 11g tymczasówki były fatalne i dalekie od into #tabelka. W sql server cte można spotkać bardzo rzadko albo jako efekt zaprzeszłości, wzięcia czegoś pierwszego lepszego lub bardzo specjalistycznych zastosowań. Sam korzystam z nich do prostej deduplilacji - w myśl zasady relacyjnej "modifikacja obiektu abstrakcyjnego, zmienia obiekt fizyczny", widziałem też bardziej analityczne zastosowania rekurencyjne, gdzie cte odwołuje się do cte. W bazach data warehouse być może zastosowanie dla cte jest większe, ale ich użycie jest zwykle bardzo problematyczne i dość niewydajne. Problemem jest jak zwykle ram, którego w HD jest zawsze za mało, a nierozważne użycie cte tylko ten problem potęguje. No i całość jest doraźna - każdorazowo zapytanie musi zostać wykonane, co przy pracach rozwojowych jest... Utrudnieniem... W zastosowaniach analitycznych unikałbym cte jak ognia, lepiej już tworzyć stałe, techniczne tabele, które po zakończeniu zostaną zdropowane. Większe zapytania wyraźnie korzystają na atomizacji, gdzie każde kolejne kroki są stosunkowo niespomplikowane, nie posiadają ani podzapytań (zwłaszcza w Select) , ani cte - korzystają z kroków poprzedzających. Uważam, że bazy Oracle bardziej nadają się do HD, pl/sql też jest dalece bardziej rozbudowany od t-sqla, ale nie rozumiem, dlaczego Oracle pokpiło tak te tymczasówki - to bardzo wygodne rozwiązanie.
Ja mam dobre doświadczenie z CTE w hurtowni, świetnie sobie radził i do tego upraszczał czytelność :) Trzeba było tylko uważać by nie nadużywać HINT-a MATERIALIZE bo łatwo zapchać pamięć, szczególnie, gdy zapisujemy w liście SELECT więcej kolumn niż de facto jest potrzebne.
A wg mnie hint "materialize" powinien być domyślny w with. Co do pierwszej wady to się nie zgodzę, trudno uznać za wadę złe użycie danego rozwiązania... Generalnie wady trochę wyciągnięte na siłę ;)
Dzięki za opinię Tomasz :) Moim zdaniem WITH służy do tworzenia logicznych bloków zapytań, które zapisane jako jeden SELECT są nieczytelne. Jeśli z kolei używamy WITH-a do prostego SELECT * FROM tabela to uzyskujemy efekt dokładnie odwrotny - zwiększamy niepotrzebnie ilość linii kodu i sprawiamy, że ktoś inny może się doszukiwać drugiego dna tego rowiązania -> "hm.. po co ktoś tu robił witha? Chodzi o plan zapytania? pewnie umie zrobić łączenie po kilku kolumnach więc po coś to jest " Ja przynajmniej miałbym takie rozkminy :) To trochę jakbyś użył funkcji analitycznej zamiast standardowego grupowania - tylko dlatego, że jest trendy i każdy pisze, że to zaawansowany SQL.
A co do materialize? Czemu tak uważasz? Jeśli ktoś do podzapytania z WITH-a będzie odnosił się tylko raz w SELEC-ie to na moje oko ten hint bardziej zaszkodzi, bo będzie narzut czasu na niepotrzebne tworzenie segmentu tymczasowego z danymi. Wtedy trzeba by pisać NOMATERIALIZE :)
@@nieinformatyk Materlizowanie czasami działa szybciej nawet jak się odwołujesz raz... na to wskazuje moje doświadczenie, ale nie dam sobie ręku uciąć.
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
Super filmik! Naturalny bez fakeowych reakcji. 7:00 to dokładnie twarz jaką ja robię kiedy kwerenda nie działa jak byłem pewien, że powinna zadziałać
Haha, staram się przygotowywać do nagrań, ale nie zawsze wychodzi idealnie w 100%:)
Fajny kanał, dopiero zaczynam przygodę z twoim kanałem, ale chętnie pooglądam filmy :) życzę dalszego rozwoju! :)
Dzięki, zapraszam do wspólnej nauki:)
Serwus Darek, w końcu znalazłem czas, aby obejrzeć Twoją lekcję. Cały czas miałem ją na liście otwartej z moim zadaniami. Teraz rozumiem czym jest CTE i powinienem go kojarzysz przede wszystkim z operacjami w hurtowniach danych. Uważam że lekcja bardzo interesująca tymbardziej, że w Internecie trudno znaleźć tak dobrze "spakowane" informacje o CTE. Pozdrawiam.
Dzięki Martin :)
@@nieinformatyk Darek a czy nagrywałeś może lekcję o instrukcji MERGE? Dzięki za Twój czas.
@@martinnereg6769 Nie, jeszcze nie nagrywałem. Znajdzie się na pewno w kursie SQL: promo.mistrzsql.pl/
W kwestii Common Table Expression (CTE) przydało by się rozszerzenie materiału o zapytania rekurencyjne "WITH RECURSIVE" 😉
Będę to dokładnie omawiał w kursie SQL: promo.mistrzsql.pl/ Porównamy też sobie RECURSIVE CTE z CONNECT BY w Oracle :)
@@nieinformatyk Nie Pomijaj też MySQL i MariaDB jako bardzo popularnych silników bazodanowych ;)
@@dariuszmion2764 w kursie omawiam każde zagadnienie na przykładzie Oracle, Sql Server i Postgres. Rozszerzanie tego na kilka kolejnych silników wydłużałoby jeszcze bardziej kurs, a tego chciałem uniknąć.
Jak zwykle materiał na najwyższym poziomie :) Pozdrawiam ;)
dzięki Bartosz :)
Dziękuję za ten film! :)
proszę bardzo :)
Hej, dziękuję, film mega przydatny. Czy planujesz jeszcze rozwinąć temat struktur drzewiastych? (Connect by prior) :)
W najbliższym czasie na YT raczej nie, bo mam już przygotowanych kilka tematów na kolejne materiały. W kursie SQL promo.mistrzsql.pl/ będzie ten temat kompleksowo poruszony: CONNECT BY (NOCYCLE), START WITH, ORDER BY SIBLINGS, LEVEL, CONNECT_BY_ISCYCLE, CONNECT BY_ISLEAF, PRIOR, CONNEC_BY_ROOT oraz SYS_CONNECT_BY_PATH. Porównamy też sobie te Oraclowe rozwiązanie z RECURSIVE CTE :)
Temat na czasie dla mnie, dzisiaj przerobiłem zapytanie z CTE na tabelki tymczasowe #. Czas z 2 minut zszedł do 1 sec :D Nie wiem jakim cudem bo zapytanie nie było jakies skomplikowane.
Brawo :)
Myślę, że ta ciągła popularność cte w Oracle jest efektem problematycznej implementacji tabel tymczasowych. Nie używałem już Oracle/pl/sqla od dłuższego czasu, ale w 11g tymczasówki były fatalne i dalekie od into #tabelka. W sql server cte można spotkać bardzo rzadko albo jako efekt zaprzeszłości, wzięcia czegoś pierwszego lepszego lub bardzo specjalistycznych zastosowań. Sam korzystam z nich do prostej deduplilacji - w myśl zasady relacyjnej "modifikacja obiektu abstrakcyjnego, zmienia obiekt fizyczny", widziałem też bardziej analityczne zastosowania rekurencyjne, gdzie cte odwołuje się do cte.
W bazach data warehouse być może zastosowanie dla cte jest większe, ale ich użycie jest zwykle bardzo problematyczne i dość niewydajne. Problemem jest jak zwykle ram, którego w HD jest zawsze za mało, a nierozważne użycie cte tylko ten problem potęguje. No i całość jest doraźna - każdorazowo zapytanie musi zostać wykonane, co przy pracach rozwojowych jest... Utrudnieniem...
W zastosowaniach analitycznych unikałbym cte jak ognia, lepiej już tworzyć stałe, techniczne tabele, które po zakończeniu zostaną zdropowane. Większe zapytania wyraźnie korzystają na atomizacji, gdzie każde kolejne kroki są stosunkowo niespomplikowane, nie posiadają ani podzapytań (zwłaszcza w Select) , ani cte - korzystają z kroków poprzedzających.
Uważam, że bazy Oracle bardziej nadają się do HD, pl/sql też jest dalece bardziej rozbudowany od t-sqla, ale nie rozumiem, dlaczego Oracle pokpiło tak te tymczasówki - to bardzo wygodne rozwiązanie.
Ja mam dobre doświadczenie z CTE w hurtowni, świetnie sobie radził i do tego upraszczał czytelność :) Trzeba było tylko uważać by nie nadużywać HINT-a MATERIALIZE bo łatwo zapchać pamięć, szczególnie, gdy zapisujemy w liście SELECT więcej kolumn niż de facto jest potrzebne.
#zasieg
CTE spoko, ale nerwy zawsze mam jak cos zakomentuje w kodzie żeby je pościć a później tego szukam w 300 linijkach.
Bywa upierdliwe. Dobrze dlatego nie przesadzać z tym cte i używać widoków i tabel zmaterializowanych. Kod robi się od razu krótszy.
A wg mnie hint "materialize" powinien być domyślny w with. Co do pierwszej wady to się nie zgodzę, trudno uznać za wadę złe użycie danego rozwiązania... Generalnie wady trochę wyciągnięte na siłę ;)
Dzięki za opinię Tomasz :) Moim zdaniem WITH służy do tworzenia logicznych bloków zapytań, które zapisane jako jeden SELECT są nieczytelne. Jeśli z kolei używamy WITH-a do prostego SELECT * FROM tabela to uzyskujemy efekt dokładnie odwrotny - zwiększamy niepotrzebnie ilość linii kodu i sprawiamy, że ktoś inny może się doszukiwać drugiego dna tego rowiązania -> "hm.. po co ktoś tu robił witha? Chodzi o plan zapytania? pewnie umie zrobić łączenie po kilku kolumnach więc po coś to jest " Ja przynajmniej miałbym takie rozkminy :)
To trochę jakbyś użył funkcji analitycznej zamiast standardowego grupowania - tylko dlatego, że jest trendy i każdy pisze, że to zaawansowany SQL.
A co do materialize? Czemu tak uważasz? Jeśli ktoś do podzapytania z WITH-a będzie odnosił się tylko raz w SELEC-ie to na moje oko ten hint bardziej zaszkodzi, bo będzie narzut czasu na niepotrzebne tworzenie segmentu tymczasowego z danymi. Wtedy trzeba by pisać NOMATERIALIZE :)
@@nieinformatyk Materlizowanie czasami działa szybciej nawet jak się odwołujesz raz... na to wskazuje moje doświadczenie, ale nie dam sobie ręku uciąć.
#zasieg
Szacun za Kimballa na półce :)
Dobra ksiazka:)
dla mnie podzapytania >>> CTE
Dzięki za podzielenie się opinią :)