- Wiersz oznacza, że wskazany użytkownik potwierdził zapoznanie się z konkretnym dokumentem.
- Powiązanie z dokumentem odbywa się przez numer referencyjny
REFNO, wspólny dla całego systemu. - Indeks złożony
REFNO_USERNAME_AKTYWNEobsługuje główne pytanie: czy ta osoba już potwierdziła. - Osobny znacznik
AKTYWNE_SSJOBpozwala usłudze przypominającej działać niezależnie od statusu wpisu.
Do czego służy tabela [dbo].[_read]
Instrukcja stanowiskowa, zarządzenie o zmianie procedury czy nowa karta charakterystyki mają wspólną cechę: samo ich opublikowanie nie wystarcza. Trzeba wykazać, że pracownicy się z nimi zapoznali. Tabela [dbo].[_read] gromadzi te potwierdzenia w formie nadającej się do przedstawienia podczas kontroli.
Konstrukcja jest prosta i przez to skuteczna. Wiersz łączy numer referencyjny dokumentu z nazwą użytkownika oraz czasem zapisu. Kolumna PRX wskazuje rodzaj dokumentu, a ACH — status wpisu. Brak wiersza oznacza brak potwierdzenia, więc raport o zaległościach sprowadza się do zestawienia listy zobowiązanych z zawartością tej tabeli.
Na uwagę zasługuje kolumna AKTYWNE_SSJOB, odrębna od zwykłego znacznika aktywności. Odpowiada za widoczność wpisu dla usługi wykonującej zadania automatyczne — najczęściej tej, która rozsyła przypomnienia o zaległych potwierdzeniach. Rozdzielenie obu znaczników pozwala wyłączyć przypominanie o konkretnym dokumencie bez naruszania samego zapisu potwierdzenia.
PublikacjaDokument trafia do systemu i otrzymuje numer referencyjny
PotwierdzenieUżytkownik zaznacza zapoznanie się, powstaje wiersz w tabeli
PrzypomnienieZadanie automatyczne wysyła monit tym, którzy jeszcze nie potwierdzili
DowódZestawienie potwierdzeń stanowi dokumentację na potrzeby kontroli
Wartość tego mechanizmu polega na tym, że brak wiersza jest równie wymowny jak jego obecność — raport zaległości powstaje bez dodatkowej ewidencji.
Budowa tabeli — wykaz kolumn
Dziewięć kolumn opisuje potwierdzenie, jego kontekst oraz sposób traktowania przez usługi automatyczne.
| Kolumna | Typ | Wymagana | Znaczenie |
|---|---|---|---|
ACH | varchar(1) tekst do 1 znaków | tak | Symbol oznaczający stan wiersza 1 - zatwierdzony |
AKTYWNE | bit wartość logiczna 0/1 | tak | Określenie czy dany wiersz tabeli jest aktywny |
AKTYWNE_SSJOB | bit wartość logiczna 0/1 | tak | Określenie czy dany wiersz tabeli jest aktywny dla usługi SSJOB |
ID__READ | int liczba całkowita | tak | Unikalny identyfikator wiersza tabeli |
KIEDY | datetime data i godzina | tak | Data utworzenia zapisu w bazie |
PRX | varchar(3) tekst do 3 znaków | tak | Symbol PRX |
REFNO | bigint liczba całkowita 64-bitowa | tak | Unikalny numer referencyjny rekordu w bazie StudioSystem |
SYSTEMOWE | bit wartość logiczna 0/1 | tak | Oznaczenie wiersza czy jest systemowy, tzn, czy podczas synchronizacji z bazą ROOT dane wiersze zostaną przegrane z bazy wzorcowej do instalacji klienta |
USERNAME | varchar(50) tekst do 50 znaków | nie | Nazwa użytkownika, dla którego zapisane jest potwierdzenie przeczytania dokumentu |
Kolumna REFNO ma typ bigint i odwołuje się do numeru referencyjnego dokumentu w tabeli źródłowej. Nie zdefiniowano dla niej klucza obcego, więc spójność powiązania wymaga kontroli po stronie aplikacji.
Indeksy i wydajność zapytań
Trzy indeksy odpowiadają trzem pytaniom, które faktycznie zadaje się tej tabeli.
| Indeks | Kolumny | Rodzaj |
|---|---|---|
PK__read | ID__READ | klucz główny |
REFNO_USERNAME_AKTYWNE | REFNO, USERNAME, AKTYWNE | zwykły |
USERNAME | USERNAME | zwykły |
Indeks REFNO_USERNAME_AKTYWNE obsługuje pytanie podstawowe — czy dana osoba potwierdziła dany dokument — i odpowiada na nie bez sięgania do samych wierszy, bo wszystkie potrzebne kolumny znajdują się w indeksie. Osobny indeks na USERNAME obsługuje widok „moje zaległe potwierdzenia”.
Potwierdzenia w praktyce: co ten mechanizm daje, a czego nie
Rejestr potwierdzeń bywa traktowany jako wystarczające zabezpieczenie prawne. Warto rozumieć, gdzie przebiega granica jego przydatności.
| Pytanie | Czy tabela odpowiada | Uwagi |
|---|---|---|
| Kto potwierdził zapoznanie się z dokumentem | Tak, jednoznacznie | Login, czas i numer dokumentu w jednym wierszu |
| Kto jeszcze nie potwierdził | Tak, przez zestawienie z listą zobowiązanych | Wymaga zdefiniowania, kogo dokument dotyczy |
| Kiedy nastąpiło potwierdzenie | Tak, z dokładnością do sekundy | Czas zapisuje serwer, nie stanowisko użytkownika |
| Czy użytkownik dokument przeczytał | Nie | Rejestr odnotowuje kliknięcie, nie zrozumienie treści |
| Której wersji dokumentu dotyczy potwierdzenie | Pośrednio | Zależy od tego, czy nowa wersja dostaje nowy numer referencyjny |
Ostatni wiersz jest najważniejszy przy wdrożeniu — decyduje o tym, czy zmiana treści wymusza ponowne potwierdzenie.
Kwestia wersjonowania rozstrzyga o wartości całego mechanizmu. Jeżeli poprawiona instrukcja zachowuje dotychczasowy numer referencyjny, wcześniejsze potwierdzenia pozostają w mocy — a pracownicy nie dowiedzą się o zmianie. Jeżeli dostaje nowy numer, potwierdzenia zaczynają się od zera i każdy musi zapoznać się z aktualną wersją. Drugie rozwiązanie jest zwykle właściwe, ale wymaga świadomej decyzji przy konfiguracji obiegu.
Jak korzystać z tabeli w praktyce
Przy korzystaniu z rejestru potwierdzeń warto pamiętać o kilku sprawach:
- Ustal przy wdrożeniu, czy nowa wersja dokumentu otrzymuje nowy numer referencyjny — to decyduje, czy zmiana wymusza ponowne potwierdzenie.
- Definiuj krąg zobowiązanych osobno; sama tabela mówi, kto potwierdził, ale nie kto miał obowiązek.
- Korzystaj ze znacznika
AKTYWNE_SSJOB, aby wstrzymać przypomnienia o dokumencie bez usuwania zapisanych potwierdzeń. - Nie usuwaj wierszy — potwierdzenie jest dowodem, a jego brak bywa interpretowany na niekorzyść pracodawcy.
- Kontroluj wpisy wskazujące nieistniejące dokumenty; brak klucza obcego nie chroni przed osieroconymi potwierdzeniami.
- Zestawiaj raport zaległości cyklicznie, a nie przed kontrolą — wtedy jest już za późno na jego uzupełnienie.
Raport zaległych potwierdzeń dla wskazanego dokumentu — lista osób, które jeszcze go nie zatwierdziły:
SELECT u.LOGIN,
u.NAZWISKO
FROM dbo._users AS u
WHERE u.AKTYWNE = 1
AND NOT EXISTS (SELECT 1
FROM dbo._read AS r
WHERE r.REFNO = @refno
AND r.USERNAME = u.LOGIN
AND r.AKTYWNE = 1)
ORDER BY u.NAZWISKO;Warunek w podzapytaniu odpowiada dokładnie kolumnom indeksu REFNO_USERNAME_AKTYWNE, dzięki czemu sprawdzenie każdego użytkownika sprowadza się do jednego przeszukania indeksu.
Rejestr potwierdzeń działa najlepiej wtedy, gdy nikt nie musi o nim pamiętać: dokument publikuje się raz, przypomnienia wychodzą automatycznie, a raport zaległości jest dostępny na żądanie. Wersja, w której ktoś raz na kwartał obdzwania dział w poszukiwaniu brakujących podpisów, technicznie też działa — tylko nie oszczędza niczyjego czasu.
Powiązane tabele i dokumentacja
Rejestr potwierdzeń łączy się z kontami użytkowników oraz pozostałymi zapisami obiegu dokumentów: