Która tabela w SELECT .. FROM .. JOIN jest główna?

1

Witam wszystkich,

Mam do was pytanie odnosnie tego kodu:

SELECT jc.jobcandidateID, pp.firstname, pp.lastname
FROM
HumanResources.JobCandidate as jc
Left join person.person as pp on jc.businessEntityID = pp.BusinessEntityID;

Moje pytanie brzmi skoro w Select mam 3 pozycje z 2 tabel, 2 POZYcje z 1 i 1 pozycja z 1. To skad mam wiedziec z ktorej tabeli jest moje FROM? po prostu z tego co znalazlem from odnosi sie do glownej tabeli? a skad mam wiedziec, ktora jest glowna? ciagle to myle dzieki za odpowiedz orly !

0

jak piszesz zapytanie to chyba wiesz co i skąd chcesz wyciągnąć

0

chlopaku zastanow sie czy jakbym wiedzial to pisalbym ten post? wiem jakie dane chce wyciagnac wiem tez skad, ale skoro dane mam w 2 tabelach to nie moge uzyc 2 tabel from? i nie moge tego zrozumiec, a staram sie to ogarnac zeby isc dalej xd

0
Cisu93miastoKrk napisał(a):

chlopaku zastanow sie czy jakbym wiedzial to pisalbym ten post?

To jak nie wiesz to trzeba albo przeczytać polecenie albo ticketa albo opis zadania czy co tam masz.

wiem jakie dane chce wyciagnac wiem tez skad,

no to wiesz czy nie wiesz

ale skoro dane mam w 2 tabelach to nie moge uzyc 2 tabel from?

możesz - ktoś ci zabronił?

Ćwiczenie na dzisiaj - opisz słownie jakie dane chcesz/masz wyciągnąć tym zapytaniem, które wkleiłeś. Gwarantuje ci, że jak to zrobisz to będziesz wiedział jak to działa

0

mozna Cie gdzies zlapac na fejsie albo gdzies? zeby cos spytac?

6

Pytaj tu, forum od tego jest.
Fejs jest od pokazania jak dobrą parówkę jesz i koło jakiego szaletu przechodzisz.

Teraz poważnie.
Zapytanie jakie wkleiłeś zawiera aliasy i jak się domyślam te aliasy Cię trochę mylą.
Jeśli masz 2 tabele to w sumie jak się zastanowisz to nie ma znaczenia do końca której użyjesz we From ważne żeby reszta się zgadzała w klauzuli join
Przykład:

Select nazwisko, pensja from pracownicy join pensje on pracownicy.id = pensje.pracownik_id`;

Select nazwisko, pensja from pensje join pracownicy on pracownicy.id = pensje.pracownik_id`;

0

no wlasnie jakby bylo tak jak mowisz, to juz dawno bym lecial dalej z kursem, niestety czasami FROM PENSJA albo pracownicy daje odmienne wyniki badz ich brak? od wczoraj utknalem na tym, a chce to zrozumiec bo inaczej nie pojde dalej!!

1

Inne wyniki będę jeśli np. będziesz miał pracownika bez pensji.
Ale wtedy wkracza do akcji co to left, right, inner, outer join. Zobacz w necie jak tłumaczone jest to na zbiorach.

W ogóle to naturalne będzie dla Ciebie za jakiś czas pisanie tych zapytań. Jeśli w głowie ułożysz sobie pytanie: znajdź wszystkich pracowników z pensja powyżej 15k to zaczniesz pisać select from employees
Zobacz tu:
Przyznam nie czytałem całego ale są ładne rysunki które powinny Ci to wytłumaczyć:
https://skillstest.pl/library/question/4

6

@Cisu93miastoKrk Jeśli korzystasz z INNER JOIN (czyli po prostu JOIN) i nie ma duplikacji kluczy głównych, to w zasadzie nie ma różnicy która tabela jest w FROM.

Ale jeśli masz LEFT JOIN, to to ma znaczenie.

  • FROM a LEFT JOIN b, wyciągnie wszystkie recordy z a, + ewentualnie doklejnone które znajdują się też w b (brakujące w b będą null).
  • FROM b LEFT JOIN a, wyciągnie wszystkie recordy które znajdują się w b plus doklejone te które znajdują się też w a (brakujące w a będą null).
0

Dobra panowie z innej paki pytanie, bo widze ze wiara jest kumata tutaj czy istnieje jakas strona na ktorej moge sprawdzac moj poziom wiedzy z sql? bo zaczynam orke straszna? dzieki za odpowiedz !

2
Cisu93miastoKrk napisał(a):

Dobra panowie z innej paki pytanie, bo widze ze wiara jest kumata tutaj czy istnieje jakas strona na ktorej moge sprawdzac moj poziom wiedzy z sql? bo zaczynam orke straszna? dzieki za odpowiedz !

np. https://www.hackerrank.com/domains/sql - masz ćwiczenia o różnym stopniu trudności i możliwość ich implementacji na różnych silnikach bazodanowych.

0
Cisu93miastoKrk napisał(a):

Dobra panowie z innej paki pytanie, bo widze ze wiara jest kumata tutaj czy istnieje jakas strona na ktorej moge sprawdzac moj poziom wiedzy z sql? bo zaczynam orke straszna? dzieki za odpowiedz !

Po prostu zacznij tworzyć aplikację, i używaj SQL po prostu jako silnika storage, do zapisywania i wczytywania danych. To nie jest tak że jakaś giga znajomość SQL jest dużo warta teraz. Jeśli chodzi o SQL, moim zdanie wystaryczy minium do tego żeby zapisać i wczytać dane, zrobić proste join'y i nałożyć indeksy, i w zasadzie tyle. IMHO.

PS: Widzę że się rodzi kłótnia w komentarzach, to może wyjaśnię. Moja rada, żeby używać SQL głównie jako silnika storage jest kierowana do @Cisu93miastoKrk i innych osób początkujących. Dodatkowo, są duże systemy w których znajomośc SQL'a przez swoją specyfikę jest niezbędna, oczywiście że są, czasami to jest nieuniknione, i tego SQL'a trzeba znać. Ale jest też druga strona medalu, jest wiele systemów w których wystarczy nałożyć cienki interfejs w języku ogólnego przeznaczenia i można stworzyć super apki z minimalną wiedzą SQL'a - jeśli miałbym taką możliwość, to właśnie ją bym wybrał, i to samo polecam wszystkim innym. Pamiętajmy ze SQL został wymyślony głównie jako interfejs do persystencji danych, oczywiście że ma funkcje, procedury i inne takie elementy, ale z reguły taką logikę lepiej napisać w general-purpose language (poza nielicznymi wyjątkami). Jedyny powód jaki znam żeby pisać taką logikę w SQL'u to jest performance.

Pozwolę sobie dorzucić moją osobistą opinię - jeśli ktoś doprowadził swój system do takiego etapu, że nie da się normalnie napisać logiki w języku programowania, tylko trzeba pisać SQLe, to coś jest grubo nie tak. Gdybym ja pracował z takim systemem, to traktowałbym bazę SQL tylko jako storage layer, a wszelkie operacje wyraziłbym w języku programowania.

0

Jedyny powód jaki znam żeby pisać taką logikę w SQL'u to jest performance.

Zacząłem pisać odpowiedź, ale teraz zauważyłem że już o tym wspomniałeś. Fajnie byłoby operować na kolekcjach, albo chociaż ich interfejsach, wyłącznie w języku programowania (czy przypadkiem LINQ tak nie działa? coś kojarzę) i nie tykać SQL, ale niestety to się totalnie nie sprawdza. W jednym projekcie głównym moim zadaniem było właśnie ratowanie wydajności, i zamiana


blahRepository.findByCustomer(currentCustomer).stream().filter(e -> e.getFoo().getBar().someDomainProperty() == 42).toList()

na coś, co wykona się w skończonym czasie (i skończonym ramie) na prodzie. Pomagało bardzo, ale może robiłem to źle.

1
kelog napisał(a):

Jedyny powód jaki znam żeby pisać taką logikę w SQL'u to jest performance.

Zacząłem pisać odpowiedź, ale teraz zauważyłem że już o tym wspomniałeś. Fajnie byłoby operować na kolekcjach, albo chociaż ich interfejsach, wyłącznie w języku programowania (czy przypadkiem LINQ tak nie działa? coś kojarzę) i nie tykać SQL, ale niestety to się totalnie nie sprawdza. W jednym projekcie głównym moim zadaniem było właśnie ratowanie wydajności, i zamiana

[...]
na coś, co wykona się w skończonym czasie (i skończonym ramie) na prodzie. Pomagało bardzo, ale może robiłem to źle.

To nie jest to co miałem na myśli. LINQ z persystencją pod spodem ma te same problemy co SQL. Miałem na myśli interfejs programistyczny wytworzony pod zadania konkretnego programu. SQL i LINQ to moim zdaniem po prostu storage layer. Ja wolałbym nie pisać w tym logiki.

0

Moje pytanie brzmi skoro w Select mam 3 pozycje z 2 tabel, 2 POZYcje z 1 i 1 pozycja z 1. To skad mam wiedziec z ktorej tabeli jest moje FROM? po prostu z tego co znalazlem from odnosi sie do glownej tabeli? a skad mam wiedziec, ktora jest glowna? ciagle to myle dzieki za odpowiedz orly !

Tutaj ładne wytłumaczenie oparte o teorię zbiorów

niestety czasami FROM PENSJA albo pracownicy daje odmienne wyniki badz ich brak? od wczoraj utknalem na tym, a chce to zrozumiec bo inaczej nie pojde dalej!!

To przecież oczywiste i wynika z tego.

Co pokrótce oznacza że na twoje pytanie nie istnieje sensowna odpowiedź.

0

@kelog @Riddle co do LINQ i podobnych wynalazków to powiem tyle - znajomy poprosił mnie abym spojrzał na jego program sprzedażowy (insert nexo) bo ma jedno zestawienie, które się nie wykonuje. Po bliższym spojrzeniu okazało się, że to wbudowane zestawienie w LINQ i nie działa bo dostaje time out po 15 minutach. Napisanie tego w SQLu zajęło może z 15 minut i wykonywało się w ~5 sekund. Opisałem problem na ich forum i w następnej wersji poprawili. Ale tylko (o ile dobrze pamiętam) na 3 kolejne updaty bo potem znowu zaczęło walić time outami.Skończyło się na tym samym zestawieniu ale napisanym jako zwykłe zapytanie SQL

0
abrakadaber napisał(a):

@kelog @Riddle co do LINQ i podobnych wynalazków to powiem tyle - znajomy poprosił mnie abym spojrzał na jego program sprzedażowy (insert nexo) bo ma jedno zestawienie, które się nie wykonuje. Po bliższym spojrzeniu okazało się, że to wbudowane zestawienie w LINQ i nie działa bo dostaje time out po 15 minutach. Napisanie tego w SQLu zajęło może z 15 minut i wykonywało się w ~5 sekund. Opisałem problem na ich forum i w następnej wersji poprawili. Ale tylko (o ile dobrze pamiętam) na 3 kolejne updaty bo potem znowu zaczęło walić time outami.Skończyło się na tym samym zestawieniu ale napisanym jako zwykłe zapytanie SQL

Ja nie mówiłem że LINQ jest lepszy niż SQL.

0
Cisu93miastoKrk napisał(a):

Witam wszystkich,

Mam do was pytanie odnosnie tego kodu:

SELECT jc.jobcandidateID, pp.firstname, pp.lastname
FROM
HumanResources.JobCandidate as jc
Left join person.person as pp on jc.businessEntityID = pp.BusinessEntityID;

SQL ma "naturalną" składnię, co czyni go nienaturalnym do zrozumienia.

Masz klauzulę "from", która określa skąd pobierane są dane. W twoim przypadku bierzesz tabelę JobCandidate, łączysz ją z person używając pól (liczba mnoga zamierzona) businessEntityID z obu tabel.
Klauzula businessEntityID oznacza, że z tej tabeli przed nią weźmiesz wszystkie wiersze, dla których znajdziesz co najmniej 1 odpowiadający wiersz w tabeli za nią. Jeżeli będzie ich więcej, to wpisy w tym wyniku zostaną powielone odpowiednią liczbę razy. Jeżeli nie będzie odpowiadającego wiersza, to również to ten z pierwszej tabeli nie zostanie wzięty pod uwagę.
Następnie SELECT określa które dokładnie kolumny z tej wynikowej tabeli mają się pokazać w wyniku.
Ponieważ nazwy pól w tej wynikowej tabeli (a właściwie widoku) mogą się powtarzać, we FROM nadajesz tym polom ksywki, w twoim wypadku jest to jc oraz pp. Te aliasy są wykorzystane do dokładnego określenia o które pole z której tabeli ci chodzi w SELECT

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.