Fantastyczny materiał! Kilka pytań: 1. W 11:30 przypisujemy nowe zmienne jako wartość dla wcześniej 'wbudowanych' w procedurę parametrów np. @ProductModel=@ProdMod. Czy tutaj kolejność jest istotna? Po lewej musi być nazwa parametru, a po prawej nazwa zmiennej, czy nie ma to znaczenia? 2. Czy w ramach dobrych praktyk, lepiej jest przypisać zmienną już na etapie DECLARE, czy dopiero wykorzystując później SET? DECLARE @Zmienna INT = 228; vs DECLARE @Zmienna INT; SET @Zmienna = 228; 3. Zabrakło w filmie informacji o parametrze wyjściowym, który może być zastosowany w procedurach. 4. Jaka jest różnica między procedurami, a funkcjami? Będzie materiał o funkcjach? 5. Czy będą może materiały dotyczące czystości pisanego kodu i dobrych praktykach? Zainteresowała mnie ostatnia odpowiedź do komentarza i przyznam, że to super sprawa. 6. Czy będą materiały dotyczące analizy danych? 7. Widzę, że co jakiś czas dochodzą nowe filmy. Ile jeszcze planuje Pan dograć? 8. O co chodzi z tym zabezpieczaniem się przed błędem? Tutaj 'IF OBJECT_ID('ProduktyWKategorii', 'P') IS NOT NULL', ale wcześniej były zabezpieczenia typu IF EXISTS. Jeśli wywali taki błąd, to reszta kodu nie zadziała, a zabezpieczenie ma gwarantować ciągłość?
1. Jeżeli nazwiemy parametry to nie musimy podawac ich w określonej kolejności, ponieważ nazwa każdego z nich mówi, która wartość dotyczy konkretnego parametru. Jeśli nie używasz nazwanych parametrów, musisz podać wartości w dokładnie tej kolejności, w jakiej są one zdefiniowane w procedurze. 2. Deklaracja jest deklaracją i to jest jej główne zadanie. Można przypisać wartość inicjującą, ale dla zwiększenie przejrzystości kodu zaleca się wykorzystać SET. 3.4. - tutaj niebawem będziemy mieli dedykowane materiały w których wyjaśnię outputy z procedur i to właśnie w kontekście porównania do funkcjami. Ponieważ funkcja zawsze zwraca wartość a procedura nie musi zwracać żadnej wartości. Może wykonywać różne operacje (np. wstawianie, aktualizowanie danych), ale jej głównym celem nie jest zwracanie wyniku. 5. Super sugestia. Wszystkie materiały na naszym kanele bazują o standardy SQL Server, ale faktycznie warto podkreślić w osobnym materiale najważniejsze best practices :) 6. Pozwolę dopytać. Chodzi tutaj o ETL? Bo jeżeli tak to na razie mamy to na liscie „To do” więc planuję w przyszłości również takie treści. 7. Kilka materiałów już czeka na publikację kilka jest w trakcie dopracowania i poprawek. 8. To zabezpieczenie ma właśnie na celu taka sama ochronę przed błędem jak „IF EXIST” w innych przypadkach. Natomiast tutaj chcemy sprawdzić czy obiekt taki jak procedura istnieje w naszej bazie. Bo jeżeli nie istnieje, tak jak sprawdziliśmy na filmie to dostaniemy błąd. No a błąd nie pozwoli nam wykonać skryptu. No chyba, że go odpowiednio przygotujemy w bloku TRY CATCH. A przykład z tego materiału po prostu pozwoli nam najpierw sprawdzić czy procedura, którą chcemy usunąć istanieje, bo możemy usuwac tylko obiekty istniejące
@@TeachTechnologyPoland 1. Muszę doprecyzować. Chodziło mi o kolejność względem znaku = Czy 'Parametr = Zmienna' da ten sam wynik co 'Zmienna=parametr'. Wstępnie miałem problem, bo coś sobie ubzdurałem, że 'równa się' to 'równa się', ale teraz myślę, że kolejność ma znaczenie, bo do lewej strony PRZYPISUJEMY wartość z prawej. 2. Ok, będę pamiętał. Widziałem różne podejścia stąd moje pytanie. 6. W zasadzie chodziło mi o wszystko, co się może przydać w analizie danych. Bo jedno to poznać narzędzie, a drugie to nauczyć się pracy z nim. Na ten moment jeszcze nie mam doświadczenia (a wiem, że sql wykorzystuje się też do analizy danych), więc zdaję się na Pana doświadczenie. 8. To jest właśnie dla mnie nieintuicyjne, bo bez względu na to który wariant wybiorę (załóżmy, że procedury już nie ma): 1. DROP bez 'zabezpieczenia' - wynik: błąd, 2. DROP z 'zabezpieczeniem' - wynik: nie wykonanie polecenia 'DROP', bo procedury nie ma. to finał będzie ten sam - procedury nie będzie już w 'systemie' (nie wiem, jak to nazwać). Chyba, że w bardziej skomplikowanych kodach, *błąd* może coś zaburzyć, a czego jeszcze nie wiem, bo póki co uczymy się na prostych kodach :D W innym kursie też nikt o tym nie wspomniał, tak że dla mnie to zagadka. W każdym razie jestem wdzięczny za materiały i tak szczegółowe odpowiedzi. Polecam już Wasz profil wśród większych kont i grup w celu promowania. Mam nadzieję, że niedługo będą efekty. Bonus 9. Czy w planach są też materiały z innych technologii? Może python, albo coś zupełnie innego, jak elektronika, czy automatyka? Nazwa kanału jest bardzo ogólna i ciekawość mnie zżera, jakie macie plany :D
@@Adrian-j5t 1. Parametr = wartość --> dokładnie taki mamy schemat. Z tego co kojarzę to w większości edytorów kodu (oraz jezyków programowania) w ten sposób działamy. 8. To tutaj możemy wyjasnie w ten sposób. W kodzie mogą trafić sie błedy, które przerywają działanie kodu, co jest najmniej pożądanym scenariuszem jaki chcemy napotkać, wieć róbmy wszystko co pozwoli nam to ominać. Jeżeli usuwanie procedury zwróci nam bład to ogólnie będzie problem. Jeżeli dokonamy sprawdzenie poprzez "IF Exists" pominiemy wystąpienie błędu, którego potencjalnego wystąpienia jestesmy swiadomi :) czyli chronimy nasz kod przed jego przerwaniem. 9. Jeżeli chodzi o dalszy rozwój i rozszenie zakresu to planujemy tematykę "Automatyzacji i Robotyzacji procesów biznesowych" oraz tematy związane z AI, ale mocno pod kątem technicznym (czyli nie jak pisać promty dla chat-gpt itp :) ) . Natomiast jeszcze przez chwilę robimy rozeznanie w potrzebach na rynku..
Fantastyczny materiał! Kilka pytań:
1. W 11:30 przypisujemy nowe zmienne jako wartość dla wcześniej 'wbudowanych' w procedurę parametrów np. @ProductModel=@ProdMod.
Czy tutaj kolejność jest istotna? Po lewej musi być nazwa parametru, a po prawej nazwa zmiennej, czy nie ma to znaczenia?
2. Czy w ramach dobrych praktyk, lepiej jest przypisać zmienną już na etapie DECLARE, czy dopiero wykorzystując później SET?
DECLARE @Zmienna INT = 228;
vs
DECLARE @Zmienna INT;
SET @Zmienna = 228;
3. Zabrakło w filmie informacji o parametrze wyjściowym, który może być zastosowany w procedurach.
4. Jaka jest różnica między procedurami, a funkcjami? Będzie materiał o funkcjach?
5. Czy będą może materiały dotyczące czystości pisanego kodu i dobrych praktykach? Zainteresowała mnie ostatnia odpowiedź do komentarza i przyznam, że to super sprawa.
6. Czy będą materiały dotyczące analizy danych?
7. Widzę, że co jakiś czas dochodzą nowe filmy. Ile jeszcze planuje Pan dograć?
8. O co chodzi z tym zabezpieczaniem się przed błędem? Tutaj 'IF OBJECT_ID('ProduktyWKategorii', 'P') IS NOT NULL', ale wcześniej były zabezpieczenia typu IF EXISTS.
Jeśli wywali taki błąd, to reszta kodu nie zadziała, a zabezpieczenie ma gwarantować ciągłość?
1. Jeżeli nazwiemy parametry to nie musimy podawac ich w określonej kolejności, ponieważ nazwa każdego z nich mówi, która wartość dotyczy konkretnego parametru. Jeśli nie używasz nazwanych parametrów, musisz podać wartości w dokładnie tej kolejności, w jakiej są one zdefiniowane w procedurze.
2. Deklaracja jest deklaracją i to jest jej główne zadanie. Można przypisać wartość inicjującą, ale dla zwiększenie przejrzystości kodu zaleca się wykorzystać SET.
3.4. - tutaj niebawem będziemy mieli dedykowane materiały w których wyjaśnię outputy z procedur i to właśnie w kontekście porównania do funkcjami. Ponieważ funkcja zawsze zwraca wartość a procedura nie musi zwracać żadnej wartości. Może wykonywać różne operacje (np. wstawianie, aktualizowanie danych), ale jej głównym celem nie jest zwracanie wyniku.
5. Super sugestia. Wszystkie materiały na naszym kanele bazują o standardy SQL Server, ale faktycznie warto podkreślić w osobnym materiale najważniejsze best practices :)
6. Pozwolę dopytać. Chodzi tutaj o ETL? Bo jeżeli tak to na razie mamy to na liscie „To do” więc planuję w przyszłości również takie treści.
7. Kilka materiałów już czeka na publikację kilka jest w trakcie dopracowania i poprawek.
8. To zabezpieczenie ma właśnie na celu taka sama ochronę przed błędem jak „IF EXIST” w innych przypadkach. Natomiast tutaj chcemy sprawdzić czy obiekt taki jak procedura istnieje w naszej bazie. Bo jeżeli nie istnieje, tak jak sprawdziliśmy na filmie to dostaniemy błąd. No a błąd nie pozwoli nam wykonać skryptu. No chyba, że go odpowiednio przygotujemy w bloku TRY CATCH.
A przykład z tego materiału po prostu pozwoli nam najpierw sprawdzić czy procedura, którą chcemy usunąć istanieje, bo możemy usuwac tylko obiekty istniejące
@@TeachTechnologyPoland
1. Muszę doprecyzować. Chodziło mi o kolejność względem znaku =
Czy 'Parametr = Zmienna' da ten sam wynik co 'Zmienna=parametr'.
Wstępnie miałem problem, bo coś sobie ubzdurałem, że 'równa się' to 'równa się', ale teraz myślę, że kolejność ma znaczenie, bo do lewej strony PRZYPISUJEMY wartość z prawej.
2. Ok, będę pamiętał. Widziałem różne podejścia stąd moje pytanie.
6. W zasadzie chodziło mi o wszystko, co się może przydać w analizie danych. Bo jedno to poznać narzędzie, a drugie to nauczyć się pracy z nim. Na ten moment jeszcze nie mam doświadczenia (a wiem, że sql wykorzystuje się też do analizy danych), więc zdaję się na Pana doświadczenie.
8. To jest właśnie dla mnie nieintuicyjne, bo bez względu na to który wariant wybiorę (załóżmy, że procedury już nie ma):
1. DROP bez 'zabezpieczenia' - wynik: błąd,
2. DROP z 'zabezpieczeniem' - wynik: nie wykonanie polecenia 'DROP', bo procedury nie ma.
to finał będzie ten sam - procedury nie będzie już w 'systemie' (nie wiem, jak to nazwać).
Chyba, że w bardziej skomplikowanych kodach, *błąd* może coś zaburzyć, a czego jeszcze nie wiem, bo póki co uczymy się na prostych kodach :D W innym kursie też nikt o tym nie wspomniał, tak że dla mnie to zagadka.
W każdym razie jestem wdzięczny za materiały i tak szczegółowe odpowiedzi. Polecam już Wasz profil wśród większych kont i grup w celu promowania. Mam nadzieję, że niedługo będą efekty.
Bonus 9. Czy w planach są też materiały z innych technologii? Może python, albo coś zupełnie innego, jak elektronika, czy automatyka? Nazwa kanału jest bardzo ogólna i ciekawość mnie zżera, jakie macie plany :D
@@Adrian-j5t
1. Parametr = wartość --> dokładnie taki mamy schemat. Z tego co kojarzę to w większości edytorów kodu (oraz jezyków programowania) w ten sposób działamy.
8. To tutaj możemy wyjasnie w ten sposób. W kodzie mogą trafić sie błedy, które przerywają działanie kodu, co jest najmniej pożądanym scenariuszem jaki chcemy napotkać, wieć róbmy wszystko co pozwoli nam to ominać. Jeżeli usuwanie procedury zwróci nam bład to ogólnie będzie problem. Jeżeli dokonamy sprawdzenie poprzez "IF Exists" pominiemy wystąpienie błędu, którego potencjalnego wystąpienia jestesmy swiadomi :) czyli chronimy nasz kod przed jego przerwaniem.
9. Jeżeli chodzi o dalszy rozwój i rozszenie zakresu to planujemy tematykę "Automatyzacji i Robotyzacji procesów biznesowych" oraz tematy związane z AI, ale mocno pod kątem technicznym (czyli nie jak pisać promty dla chat-gpt itp :) ) . Natomiast jeszcze przez chwilę robimy rozeznanie w potrzebach na rynku..
W playliście brakuje filmu z pierwszą częścią procedur składowanych, która - jak widzę - ogólnie jest na kanale :)
Dzięki za info :) już poprawione!