Łączenie tabel SQL, czyli jak używać instrukcji SQL JOIN (wszystkie metody)

แชร์
ฝัง
  • เผยแพร่เมื่อ 10 พ.ย. 2024

ความคิดเห็น • 40

  • @alexandervaldez5605
    @alexandervaldez5605 2 ปีที่แล้ว +3

    Bardzo treściwy materiał i po 'ludzku' wytłumaczone co z czym się łączy, wiele filmików na temat joinów nie porusza tematów roszady tabel np przy left joinie a Ty pokazujesz i tłumaczysz. Czekam na dalszy rozwój o tym czego nie zakreśliłeś na zielono, więcej tabel , wyrażenia na kolumnie.

    • @nieinformatyk
      @nieinformatyk  2 ปีที่แล้ว +1

      Dzięki Alexander za komentarz :)

  • @marekt8465
    @marekt8465 ปีที่แล้ว

    Świetny materiał! Powinieneś wykładać na politechnice. I mówię to całkiem poważnie. Jeżeli przyswoiłeś te wszystkie pozycje o bazach danych, które masz na półkach to wiedzę z baz danych masz pewnie większą od niejednego prowadzącego ten przedmiot na studiach informatycznych. Mega szacunek dla Ciebie za tę robotę! Pozdrawiam i dziękuję za wszystkie materiały.

    • @nieinformatyk
      @nieinformatyk  ปีที่แล้ว +2

      Dziękuję :) kariera wykładowcy mnie nie interesuje, do większej liczby osób dotrę materiałami na yt.

  • @monikaflem
    @monikaflem ปีที่แล้ว

    Bardzo fajny materiał, dziękuję.

  • @pawepuszka858
    @pawepuszka858 2 ปีที่แล้ว

    Dzięki za materiał. Jak zwykle samo "mięcho" :) Pozdrawiam

  • @koloyolo7629
    @koloyolo7629 ปีที่แล้ว

    fajny odcinek, bardzo chętnie obejrzałbym rozszerzenie :)

    • @nieinformatyk
      @nieinformatyk  ปีที่แล้ว

      musisz poczekać kilka miesięcy - tutaj będzie o joinach cały kilkunasto-odcinkowy moduł :) promo.mistrzsql.pl/

  • @jakubkozie2631
    @jakubkozie2631 2 ปีที่แล้ว

    Super materiał. Czekam na kolejne kursy dotyczące PL/SQL

    • @nieinformatyk
      @nieinformatyk  2 ปีที่แล้ว

      dzięki :) a brakuje czegoś w tym szkoleniu czego potrzebujesz? plsql.pl/

    • @jakubkozie2631
      @jakubkozie2631 2 ปีที่แล้ว

      Nie pisałeś kiedyś że będziesz pracował nad kursem dotyczącym optymalizacji?

    • @nieinformatyk
      @nieinformatyk  2 ปีที่แล้ว +1

      @@jakubkozie2631 tak, to prawda :) ale pytałeś o pl/sql, więc zwątpiłem.
      Najpierw pojawi się kurs SQL, potem hurtowni danych/ETL, a potem optymalizacji

    • @jakubkozie2631
      @jakubkozie2631 2 ปีที่แล้ว

      Wow, świetne informacje przekazujesz:)

  • @xavrock1112
    @xavrock1112 2 ปีที่แล้ว

    Witam. Czy zostanie poruszony temat Master Data ? Oraz zasady ich przechowywania ? Po wykładzie czuję mocne niezrozumienie tematu, z naciskiem na ich przechowywanie. Myślę że taki odcinek mógłby pomóc również innym. Ciężko jest znaleźć jakiś dobry materiał w internecie.

    • @nieinformatyk
      @nieinformatyk  2 ปีที่แล้ว +1

      Od dłuższego czasu myślę o odcinku z taką roadmapą bazodanowca i opisem technologii/narzędzi do zarządzania danymi. Póki co nie wymyśliłem jednak jakiejś sensownej formuły na taki odcinek, więc mogę powiedzieć, że na pewno się pojawi, ale raczej nie w najbliższych tygodniach/miesiącach :)

  • @krzysztofm2433
    @krzysztofm2433 ปีที่แล้ว

    mógłbyś nagrać filmik o instrukcji selfjoin?

    • @nieinformatyk
      @nieinformatyk  ปีที่แล้ว

      zapraszam, będzie dedykowana lekcja :) promo.mistrzsql.pl/

  • @mrCajmerek
    @mrCajmerek 11 หลายเดือนก่อน

    Jakiego SZBD używasz?

    • @nieinformatyk
      @nieinformatyk  11 หลายเดือนก่อน

      W nagraniu Oracle, w pracy Oracle + Postgres.

  • @TomaszTomzik
    @TomaszTomzik 2 ปีที่แล้ว +1

    W zasadzie napisałem miliony złączeń, ale staram się aby zawsze użyć LEFT, tak ustawiam tabele, nie miałem nigdy potrzeby zrealizowania złączenia prawego... nie chce mi się szukać po Internetach, kiedy to się przydaje... ale takie spostrzeżenie.

    • @nieinformatyk
      @nieinformatyk  2 ปีที่แล้ว

      ja też nigdy RIGHT nie używam - przydaje się w tych samych sytuacjach co LEFT :)

  • @kozlo1
    @kozlo1 ปีที่แล้ว

    14:10 Po co wiec pisze się constrainty foreign key skoro można joinować bez tego? Żeby komputer umiał zrobić NATURAL JOIN?

    • @nieinformatyk
      @nieinformatyk  ปีที่แล้ว +1

      Po to by pilnować spójności danych. Jeśli nie stworzysz contrainta to nie masz gwarancji, że w tabeli, np. z pracownikami nie znajdzie się w kolumnie id_departamentu identyfikator, który nie wskazuje na żaden departament.
      Constraint jest do tego by pilnować by każda wartość klucza obcego istniała w kluczu głównym, na który ten constraint wskazuje.
      A łączenie to po prostu łączenie tabel. Możesz joinować co Ci się jawnie podoba, choć dobrze by miało to sens :)

  • @Twena1
    @Twena1 ปีที่แล้ว

    O co chodzi z tymi aliasami, jak je napisać, oznaczyć, itp.?

    • @nieinformatyk
      @nieinformatyk  ปีที่แล้ว

      Alias to po prostu tymczasowa nazwa wyrażenia/kolumny lub obiektu z którego czytamy dane(tabela/widok/podzapytanie). Tworzenie aliasu to słowo AS a po nim nazwa aliasu(choć AS jest opcjonalne).
      Po co to używamy? Bo kod staje się czytelniejszy, łatwiejszy w utrzymaniu a czasem nawet wydajniejszy. Więcej o aliasach będę mówił w tym szkoleniu: promo.mistrzsql.pl/

    • @Twena1
      @Twena1 ปีที่แล้ว

      @@nieinformatyk Ok, ale jak zapisać to, np. w twoim kodzie źródłowym? AS produkty? I co, wtedy pojawi się pierwsza litera "p" zamiast produkty czy jak? Możesz mi zapisać ten wiersz? Dzięki.

    • @nieinformatyk
      @nieinformatyk  ปีที่แล้ว

      @@Twena1 Aliasów używa się w poleceniach DML czyli INSERT, UPDATE, DELETE i SELECT.
      -- brak aliasu i niewskazywanie z jakiej tabeli pochodzi kolumna
      SELECT id
      FROM pracownicy;
      -- brak aliasu i używanie pełnej nazwy tabeli
      SELECT pracownicy.id
      FROM pracownicy;
      -- użycie aliasu (zalecana praktyka)
      SELECT p.id
      FROM pracownicy p;
      Sens używania aliasów widać przy złożonych zapytaniach, zwłaszcza gdy łączymy tabele.

  • @modzelem
    @modzelem 2 ปีที่แล้ว

    9:45 zabrakło sprawdzenia typu kolumny.

    • @nieinformatyk
      @nieinformatyk  2 ปีที่แล้ว

      przecież obie kolumny to VARCHAR2 -> nie jest tu wymagana, ani nawet wskazana żadna konwersja

    • @modzelem
      @modzelem 2 ปีที่แล้ว

      @@nieinformatyk w tym wypadku tak, ale warto sprawdzić co łączymy

    • @nieinformatyk
      @nieinformatyk  2 ปีที่แล้ว

      @@modzelem to fakt

  • @TomaszTomzik
    @TomaszTomzik 2 ปีที่แล้ว

    Ja wiem, że to do potrzeb tematu... ale jak widzę, taką tabelę z typami gdzie kluczem głównym jest wartość tekstowa (nawet skrócona) to krew mnie zalewa... nie uczmy czegoś takiego nowicjuszy...

    • @nieinformatyk
      @nieinformatyk  2 ปีที่แล้ว +1

      W każdym nagraniu da się do czegoś przyczepić -> jakbym stworzył klucz INTEGER to ktoś przyczepiłby się, że nazwy tabel są po polsku, a nie po angielsku. Może to naiwne, ale w każdym nagraniu staram się kierować uwagę na jedną rzecz, w tym przypadku łączenie tabel. Typ danych klucza PK to zagadnienie, które fajnie omówić przy okazji klucza sztucznego/naturalnego oraz optymalizacji zapytań indeksami/rozmiaru bazy danych.
      Nie zmienia to faktu, że dobrze, że na to zwróciłeś uwagę. Mam nadzieję, że ktoś przeczyta Twój komentarz i zacznie się zastanawiać dlaczego VARCHAR2 nie jest fajny :)

    • @piniekpinio
      @piniekpinio 2 ปีที่แล้ว

      Przecież widać że zrobione aby było łatwiej zrozumieć laikom. Jakby tam były numery to byliby mniej przejrzyyste.

    • @TomaszTomzik
      @TomaszTomzik 2 ปีที่แล้ว

      @@nieinformatyk jeśli ktoś się do czegoś przyczepi, znaczy się, że ktoś ogląda z uwagą. Ps nazwy obiektów nie są tak destrukcyjne jak takie klucze główne;)

    • @TomaszTomzik
      @TomaszTomzik 2 ปีที่แล้ว

      @@piniekpinio nie wiem czemu założyłeś, że tego nie wiem... skoro napisałem "do potrzeb tematu" - ale napisałem również, że mimo wszystko to jest "świętokractwo" i totalna zguba... ;)

    • @piniekpinio
      @piniekpinio 2 ปีที่แล้ว +1

      @@TomaszTomzik Jeżeli wszystko wiesz to nie wiesz, że tak formą podcinasz skrzydła autorowi. Lepiej byłoby przyjęte "Zapomniałeś wspomnieć, że klucze główne bezpieczniej jak są numeryczne niż tekstowe". Teraz w odpowiedzi daj link z filmikiem Twojego wykonania zrobionym lepiej :)