Zielony SQL, dorobił się bazy testowej :-)
Zielony SQL, dorobił się bazy testowej :-)
Dostępna jako plik do podczepienia w MS SQL SERVER EXPRESS, plik z rozszerzeniem mdf jest pod linką poniżej.
W tej lokalizacji też kilka slajdów jak ten plik podczepić do Servera przy użyciu STUDIA.
Tabelek jest tam całkiem dużo, bo to nieco śmietnik się zrobił, to też tam są tabelki wykorzystywane do wcześniejszych postów. Główne i najpełniejsze to te niżej wymienione.
/*
NA TYM PRACUJEMY
select * from kostka_umowy;
select * from klienci;
select * from kontrakt_start;
select * from portfel;
*/
https://drive.google.com/drive/folders/0B0DNBH1DOPAfc3dwU1EwZ0FoR0k?usp=sharing
ZNOWU LAG, nie mamy danych z dni wolnych w miesiącu, to jak uzupełnić dane?
ZNOWU LAG, nie mamy danych z dni wolnych w miesiącu, to jak
uzupełnić dane?
Lepiej późno niż wcale, powiedziała pewna pani, gdy na
pociąg się spóźniła… Pewną zagadkę swego czasu rozwiązywałem, rozwiązywałem, a
później temat stał się nieaktualny :-)
Opis sytuacji:
W dni robocze są ładowane dane do hurtowni. Po prostu dla
każdego dnia roboczego jest dostępna informacja o saldzie środków na koncie
danego Klienta.
Odsetki płacimy za każdy dzień trzymania środków u nas przez
Klienta, ale także za dni wolne.
Robimy plan kosztów na kolejny rok. Mamy dane z jednego stycznia 2012 roku.
No to cóż, trzeba policzyć średnie saldo w miesiącu środków,
to saldo pomnożyć przez stopę procentową, według której płacimy odsetki i już wiemy ile zapłacimy Klientowi.
No właśnie, ale jak ma się średnia obliczona na danych w
hurtowni z dni roboczych do średniej policzonej na wszystkich dniach w
miesiącu. Jak uzupełnić informację o salda z niezaładowanych dni?
Oto jest pytanie?
Prezentacja problemu, dane, kody i tak dalej. Wszystko w
lokalizacji poniżej. A rozwiązanie to połączenie wykorzystania COALESCE i LAG
(w przypadku Oracle to wykorzystać należy Marcinie NVL2 i LAG).
Jak nie lagą (taki kij) to go leadem...
Była promocja i tym podobne, posty, posty, a brak nowych
treści odnośnie SQL.
Zatem poprawiam się, polecam książkę po raz wtóry:
A w tej książce na stronie 71 jest:
Nie po
raz pierwszy staje się bardzo widoczny nacisk producentów baz danych na przetwarzanie
analityczne. Praktycznie z każdą nową realizacją produktu wprowadzane są nowe
funkcjonalności.
Już nie tak nowe, ale dwie wymienię
LAG (w moich stronach, laga to taki kij) lub LEAD. To fajne funkcje jeżeli
chcemy szybko policzyć zmiany, ale hurtem,
wskaźniki procentowe, ale chcemy na przykład wziąć wartość do licznika z
danego wiersza, a do mianownika wartość z innego wiersza, np.
3 wiersze wstecz, jeżeli je posortować według daty6 (innego pola, ale sortowanie
musi być, bo w bazie dane nie są posortowane tak jak mam intuicyjnie się
wydaje, to błąd).
Tu są dwie funkcje do stosowania, LAG i LEAD, różnica pomiędzy nimi jest taka, że LAG bierze wartość wstecz, przesunięcie wstecz, a LEAD wprzód. Nie da się wpisać w LAG lub w LEAD wartości ujemnej na drugim miejscu w nawiasie: sprawdziłem.
Obie funkcje mają w nawiasie do wypełnienia trzy parametry:
Pierwszy jest obowiązkowy, trzeba podać z jakiego pola ma zapytanie pobrać wartość.
Drugi już nie jest obligatoryjny, jak pominiesz, to baza przyjmie domyślnie 1.
Jak trzeci pominiesz, to domyślnie baza przyjmie NULL
Tu są dwie funkcje do stosowania, LAG i LEAD, różnica pomiędzy nimi jest taka, że LAG bierze wartość wstecz, przesunięcie wstecz, a LEAD wprzód. Nie da się wpisać w LAG lub w LEAD wartości ujemnej na drugim miejscu w nawiasie: sprawdziłem.
Obie funkcje mają w nawiasie do wypełnienia trzy parametry:
Pierwszy jest obowiązkowy, trzeba podać z jakiego pola ma zapytanie pobrać wartość.
Drugi już nie jest obligatoryjny, jak pominiesz, to baza przyjmie domyślnie 1.
Jak trzeci pominiesz, to domyślnie baza przyjmie NULL
Ten NULL to ma zastosowanie jeżeli np. jest to pierwszy wiersz z sortowania, to 3 wstecz to co podać? Domyślnie jest NULL, ale możesz wskazać inną wartość.
LAG (nazwa pola, przesunięcie1, wartość domyślna)
LEAD
(nazwa pola, przesunięcie2, wartość domyślna)
A więc ww. LAG i LEAD działają jedynie na posortowanych wynikach, zatem po:
A więc ww. LAG i LEAD działają jedynie na posortowanych wynikach, zatem po:
LAG lub LEAD musi być słowo kluczowe OVER a
następnie w nawiasie minimum (ORDER BY nazwa pola).
W tym nawiasie może być jeszcze „partition by” ale to na teraz proszę Marcinie daj spokój, nie za dużo.
Zobacz na przykładzie, tu zwróć uwagę, że pokazuję działanie LAG i LEAD na danych w tabeli portfel, która zawiera już włożone agregowane dane (bo to przykład), ale zamiast odwołania do tabeli portfel może i często w nawiasie bywa długi SELECT z funkcjami agregującymi, to wówczas widać finezję stosowania LAG i LEAD.
W tym nawiasie może być jeszcze „partition by” ale to na teraz proszę Marcinie daj spokój, nie za dużo.
Zobacz na przykładzie, tu zwróć uwagę, że pokazuję działanie LAG i LEAD na danych w tabeli portfel, która zawiera już włożone agregowane dane (bo to przykład), ale zamiast odwołania do tabeli portfel może i często w nawiasie bywa długi SELECT z funkcjami agregującymi, to wówczas widać finezję stosowania LAG i LEAD.
Potestuj działanie LAG i LEAD, a może się przekonasz do
stosowania :-)
W tej lokalizacji znajdziesz dane wsadowe, kwerendy, prezentację.
W tej lokalizacji znajdziesz dane wsadowe, kwerendy, prezentację.
Subskrybuj:
Posty (Atom)