Podzapytania SQL - podstawy z przykładami

Поділитися
Вставка
  • Опубліковано 3 лис 2024

КОМЕНТАРІ • 17

  • @RobieMVPAplikacjeKarolBocian
    @RobieMVPAplikacjeKarolBocian 9 місяців тому +3

    Super film, dziękuję!!!
    🥰
    😍
    🤩

    • @nieinformatyk
      @nieinformatyk  9 місяців тому +1

      Polecam się na przyszłość :)

  • @Hertil
    @Hertil 9 місяців тому +1

    Cześć. Dlaczego roadmapa nie jest dostępna do pobrania? Dawno temu zapisałem się na newsletter, mam nawet wykupione szkolenie PL/SQL ale nie otrzymałem nigdy roadmapy. Trochę wprowadza w błąd ten komunikat wyświetlany w filmie.

    • @nieinformatyk
      @nieinformatyk  9 місяців тому

      Jest dostępna, nic nie się zmieniło odkąd pojawił się pierwszy odcinek z tej serii. Roadmapa jest do pobrania poprzez link, który otrzymasz w wiadomości wysłanej automatycznie po zapisie na ten newsletter: promo.mistrzsql.pl/ Poza tym każda osoby zapisana na którejkolwiek z moich innych newsletterów mogła pobrać tę roadmapę, bo wysyłałem do niej link - jeśli dobrze pamiętam to było to nawet nim pojawił się odcinek na YT.
      Jeśli zapisywałeś się już na ten newsletter to napisz na priv podając swój e-mail - wyślę Ci link do miejsca, gdzie możesz PDF pobrać.

  • @zmudakrzysztof
    @zmudakrzysztof 9 місяців тому

    10:02
    do czego służy ON 1=1 w 46 wierszu?

    • @nieinformatyk
      @nieinformatyk  9 місяців тому +2

      U mnie w kodzie jest po to by zrobić iloczyn kartezjański, czyli połączyć każdy rekord z każdym. Równie dobrze mógłbyś użyć CROSS JOIN.
      1=1 możesz też spotkać w WHERE. To dobra praktyka pisania zapytań, ponieważ pozwala wygodnie komentować warunki WHERE w trakcie pracy nad kodem. Porównaj oba te przykłady:
      1) Jeśli chcesz zakomentować/wyrzucić pierwszy z warunków to musisz się więcej napracować, bo komentując całą linijkę zakomentujesz też WHERE i kod będzie niepoprawny.
      WHERE id_pracownika = 1
      AND pensja > 5000;
      2) Tutaj WHERE 1=1 zostaje zawsze, ale nic nie robi. Wystarczy dodać --(komentarz) i warunek wyeliminowany.
      WHERE 1=1
      AND id_pracownika = 1
      AND pensja > 5000;

  • @mordor1410
    @mordor1410 9 місяців тому

    Zamiast podzapytania w where zawsze wybiore CTE z uwagi na czytelnosc kodu. Duzo latwiej mi sie czyta kod napisany cte niz z 10 podzapytaniami.

    • @nieinformatyk
      @nieinformatyk  9 місяців тому

      Też wolę CTE, ale takie rozwiązanie ma również wady: ua-cam.com/video/VMErIoxFSTU/v-deo.html

    • @mordor1410
      @mordor1410 9 місяців тому

      @@nieinformatyk oczywiście, warto myśleć przy pisaniu. Ja pracuję głównie na chmurze Google, więc do wydajności trzeba podejść zupełnie inaczej niż w relacyjnych bazach

    • @nieinformatyk
      @nieinformatyk  9 місяців тому

      @@mordor1410 Google Big Query? Rozwiniesz temat?

    • @mordor1410
      @mordor1410 9 місяців тому +1

      @@nieinformatyk Tak, BigQuery. Pracuje się tu na kolumnach a nie na wierszach, co wymusza, że trzeba zmienić trochę sposób myślenia. Co więcej, pricing za każdą podniesioną daną powoduje iż zapytania trzeba nieco dokładniej przemyśleć (płacisz za każde zapytanie), za to nieefektywne np. Select * from możesz zapłacić horrendalnie dużo bez żadnej wartości dodanej. W zamian masz bezobsługowe działanie, gigantyczną moc obliczeniową (choćbym "przerzucał" 10 TB danych to ponad minutę wykonywania poleceń nie poszedłem), ale z drugiej strony BQ z funkcjami okienkowymi się nie lubi - wykonywanie takich zapytań trwa dłużej niż można przewidzieć.
      Wrzuciłbym materiał, który lepiej opisuje różnice, ale wtedy moje komentarze chyba dostają shadowbana ;)

    • @nieinformatyk
      @nieinformatyk  9 місяців тому

      @@mordor1410 dzięki za linka na priv :) Jasna sprawa - kolumnowe i rekordowe bazy danych to zupełnie inna architektura. O opłacie za wykonanie każdego polecenia sam już wcześniej myślałem - to duża zmiana(akurat na minus), że nie można sobie betrosko testować poleceń, a w razie czego ich ubić.

  • @kapitalis4412
    @kapitalis4412 9 місяців тому

    Zgodzę się, że SQL nauczenie się podstaw jest proste, ale zastosowanie tych prostych mechanizmów w bardziej złożonej całości wymaga już eksperymentowania i kreatywności. Jak klocki lego, gdzie przy użyciu wielu podobnych można tworzyć ciekawą konstrukcję i niekoniecznie trzeba tam jakichś wyspecjalizowanych elementów. Tabel przestawnych SQL na przykład nigdy nie stosowałem w pracy.

    • @nieinformatyk
      @nieinformatyk  9 місяців тому

      Tu tkwi największa trudność SQL-a. Podstawy łatpie się szybko, ale zdobycie zaawansowanej znajomości wymaga dużo więcej wysiłku, czego nie rozumieją osoby piszący w internecie komentarze, że SQL ogarniesz w 3 tygodnie/miesiące :)

    • @kapitalis4412
      @kapitalis4412 9 місяців тому

      @@nieinformatyk myślę, że w 3 intensywne miesiące można opanować na tyle, żeby zdać test w pracy na poziomie kolokwium ze studiów i mieć podstawowy warsztat, a potem największy rozwój na konkretnych problemach do rozwiązania