Trigger czyli wyzwalacz

Trigger czyli wyzwalacz. Tak, jest coś takiego, to już rozszerzenie SQL. Występuje na pewno na MS SQL Serwerze oraz na bazach ORACLE. Ponieważ opisuję triki, które sam stosowałem, to w zakresie rozszerzenia SQL szału nie ma, ale jakieś triggery stosowałem…

Zatem sytuacja wygląda następująco: co roku zbieramy dane o przychodzie i dochodzie klienta. Jest wypełniany formularz w EXCEL i przekazywanych do centrali.  Wymyśliliśmy to tak, że każdy z formularzy miał wbudowaną formułę konstruującą odpowiednie polecenie INSERT…, którego wykonanie powodowało dopisanie danych do bazy. To, że tak powiem była pierwsza generacja, w kolejnej już mieliśmy postawioną osobna bazę i podpięty formularz internetowy do wprowadzania danych.  

I powstało pytanie, czy nie zapiszemy danych, które już mamy, za rok który już mamy.  Projektowanie komunikacji w dwie strony dla wpisującej osoby nie wchodziło w grę, to kosztowne i wymagające zachodu podejście, po prostu bez sensu, jak na realizowany cel: bieranie danych.  No to zapisywaliśmy jak leci, co tylko do nas dotarło, do tabeli na bazie: KLIENT_WYNIKI.

Na tej tabelce został zbudowany, założony trigger, tu nazywam go:  DODAJ_DATE_ZAPISU. Trigger uruchamia się po każdym insercie do tabelki KLIENT_WYNIKI. 

Trigger powoduje, iż do drugiej tabelki o nazwie KLIENT_WYNIKI_TOTAL wykonuje się insert/załadowanie danych tych samych co zainsertowanych ostatnio do KLIENT_WYNIKI, cały wiersz w całości insertowany  plus uzupełniana jest dodatkowa kolumna zawierające informację o dacie i czasie ładowania, tu wykorzystywana jest GETDATE().

Przyjmujemy teraz, że dane załadowane najmłodsze  są najlepsze, dlatego widok,  który używamy do celów raportowych wybiera dla każdego klienta ostatnio ładowane dane. 

To tak z grubsza, oczywiście pominąłem tu kilka wątków, np. jak rodzaje źródeł danych etc. To nie jest istotne dla pokazania idei działania triggera jednak, za dużo by tego było.

Pewno i by obyło się bez dwóch tabel, jedna by wystarczyła, można nie insert, można update. To jak kto lubi, jak wymyśli, dostosuje do swoich potrzeb. 

Tutaj kod, obrazki, do poćwiczenia.

 

FISZKI

Fiszki

Na FB publikuję, że tak powiem fiszki dotyczące SQL, tu te same plus ekstra kody SQL gdybyście chcieli poćwiczyć to co na obrazkach.

Tutaj.

 

Wolne krzesła na sali kinowej, szukamy selectami...

Problem  jest jak na obrazku, jest sala kinowa, niektóre miejsca są już sprzedane, przychodzi 6  osób i jak szybko namierzyć najlepszą…dla nich lokalizację, by wszyscy siedzieli obok siebie.

Człowiek to sobie patrzy, oczyma zlokalizuje, policzy, wie… (jakaś większość na pewno sobie z tym radzi). A aplikacja czy też strona internetowa tak jak my ludzie to tego nie zrobi.  

Aplikacja jest najprawdopodobniej spięta z jakimś systemem zarządzania bazą (np. MySQL) i musi  mieć algorytm. My sobie klik a tam kwerendy się wykonują między innymi. 

I przygotowałem rozwiązanie, selecty, widoki etc. Tak by tylko wystarczyło podać ile miejsce jest potrzebnych i wyświetla się lista propozycji od najwyższego. 

Prezentacja, kwerenda, opis dostępny tu:

https://drive.google.com/drive/folders/0B0DNBH1DOPAfaVhIR3dsb09RZms?usp=sharing

 

W przykładzie już są jakieś zajęte miejsca, to dla celu prezentacji rozwiązania, ale przecież masz dostęp do bazy, to jak sprzedamy np. miejsce nr 5 w rzędzie B, to my klik, a tam uruchamiają się kwerendy:

update

sala_kinowa

set status='X'

where rzad='B' and miejsce=5;

update

sala_kinowa

set status_opis='SOLD'

where rzad='B' and miejsce=5;

I już będzie nowy zestaw luk.

 select * from v_luki;

Przykład zaczerpnięty ze strony 193, książki MS SQL Server zaawansowane metody programowania autorstwa Adama Pelikanta, wydawnictwo Helion.