Bazy danych, czyli czego pani Agnieszka nie chowa pod skarpetkami

Po pożarze Centralnego Magazynu Dokumentów, odbudowie RAID-u, przygodach z backupami i zaszyfrowanym sejfem przyszła pora na najbardziej niezawodny element firmy: panią księgową Agnieszkę. Faktury zna na pamięć, rozliczenia potrafi znaleźć z zamkniętymi oczami, a na pytanie „jaki silnik bazy danych?” odpowiada: „Pan Grzesiu wie”. W jej pokoju stoją segregatory, komputer, drukarka i szuflada ze skarpetkami. I właśnie tam kierownik postanawia przeprowadzić rewolucję. Dziś nie uczymy się pisać SQL-a. Sprawdzamy, jak nie zgubić, nie ujawnić, nie popsuć i naprawdę odzyskać dane — niezależnie od tego, w czym są przechowywane.

Rozdział pierwszy: pani Agnieszka wie, czego nie dotykać

— PANI AGNIESZKO! GDZIE JEST NASZA BAZA DANYCH?!
— W komputerze, panie kierowniku.
— W KTÓRYM?!
— W tym szarym. Ale pan Grzesiu mówił, żebym nie szukała jej sama.
— TO PANI NIE WIE, GDZIE SĄ DANE?!
— Wiem, gdzie mam faktury, deklaracje i rozliczenia. A gdzie je technicznie zapisuje program, wie pan Grzesiu.
— TO JAK PANI ROBI BACKUP?!
— Klikam zielony przycisk, potem sprawdzam wiadomość od pana Grzesia.
— CZYLI PANI NIE WIE, CO PANI ROBI?!
— Wiem. Księguję. A od baz jest pan Grzesiu.

🤣🤣🤣

Pani Agnieszka jest profesjonalną szczęściarą: technicznie czasem zgaduje, zawodowo zna się na swoim, a przy ważnych sprawach dzwoni do właściwego człowieka. I to jest całkiem przyzwoita zasada bezpieczeństwa: nie każdy musi być administratorem bazy, ale ktoś musi odpowiadać za jej ochronę, kopie i odzyskiwanie.

„Baza danych” oznacza uporządkowany zbiór informacji i mechanizmy służące do ich przechowywania oraz używania. Może działać na osobnym serwerze, w lokalnym pliku, wewnątrz aplikacji, a zwykły arkusz kalkulacyjny również bywa wykorzystywany jako prosta ewidencja. Narzędzia różnią się możliwościami, ale faktury i dane klientów wymagają ochrony niezależnie od rozszerzenia pliku.

Rozdział drugi: bazę można mieć nawet wtedy, gdy się o tym nie wie

— PANI AGNIESZKO! MAMY JEDNĄ BAZĘ DANYCH!
— A tę w programie księgowym?
— JEDNĄ!
— A ewidencję urlopów w Excelu?
— TO TYLKO EXCEL!
— A grafik w Arkuszu Google?
— TO CHMURA!
— A program magazynowy sprzed piętnastu lat?
— TO ZABYTEK!
— Panie kierowniku, wszystkie przechowują jakieś dane — mówi pan Grzesiu.
— TO PROSZĘ JE WSZYSTKIE PRZEMIANOWAĆ NA „BAZA”! BĘDZIE PORZĄDEK!

🤣🤣

W firmie spotykamy serwerowe silniki takie jak MySQL, MariaDB, PostgreSQL, Microsoft SQL Server czy Oracle; bazy osadzone lub plikowe, na przykład SQLite i Access; starsze rozwiązania takie jak Pervasive/Btrieve (dziś spotykane również pod nazwą Actian Zen); a obok nich arkusze i ewidencje w Excelu, LibreOffice Calc czy Google Sheets. Istnieją też bazy dokumentowe, np. MongoDB, oraz magazyny klucz–wartość, np. Redis — ich zastosowania i sposób trwałego zapisu są różne.

To nie ranking „dobre i złe”. SQLite jest prawdziwą relacyjną bazą danych, mimo że nie potrzebuje osobnego procesu serwera. Access potrafi obsługiwać relacje i formularze, a Pervasive nie sprowadza się do zwykłego „pliku w folderze” w każdej konfiguracji. Sam arkusz też może być świetnym narzędziem dla małej ewidencji. Problem zaczyna się, gdy nie wiemy, gdzie są dane, kto ma do nich dostęp i co stanie się po awarii.

Rozdział trzeci: przenosimy program, a faktury zostają

— PANI AGNIESZKO! KUPIŁEM NOWY KOMPUTER!
— Jak miło.
— PRZENIOSŁEM NA NIEGO IKONKĘ PROGRAMU KSIĘGOWEGO!
— A bazę też?
— PRZECIEŻ IKONKA JEST!
— Panie kierowniku, ikonka nie jest bazą — wtrąca Grzesiu.
— TO PO CO ONA TAM STOI?!
— Żeby uruchomić program, który łączy się z właściwymi danymi.
— PROSZĘ NIE WMAWIAĆ MI, ŻE MOJA IKONKA NIC NIE WIE!

🤣🤣

To samo oprogramowanie może korzystać z różnych sposobów przechowywania danych. W określonych wersjach i konfiguracjach programów księgowych — przykładem jest znany w Polsce Płatnik — spotyka się lokalne rozwiązania oparte na Accessie lub wariant z Microsoft SQL Server. Inny program może trzymać SQLite w profilu użytkownika, a kolejny łączyć się z serwerem PostgreSQL lub MySQL. Konkretne formaty i warianty trzeba zawsze sprawdzić w dokumentacji używanej wersji.

Przeniesienie samej aplikacji nie musi przenieść danych. Niekiedy potrzebne są również pliki bazy, dzienniki, konfiguracja połączenia, certyfikaty, licencja i zgodne środowisko. Zanim wymienimy komputer albo przeinstalujemy program, ustalamy faktyczne miejsce przechowywania danych i sprawdzamy procedurę migracji oraz odtworzenia.

Rozdział czwarty: kartka na monitorze? Nigdy!

Pan Grzesiu zagląda do księgowości.

— Pani Agnieszko, cieszę się, że nie przykleja pani haseł do monitora.
— No przecież! To nieprofesjonalne!
— Doskonale. To gdzie pani mówiła, że je przechowuje?
— Pod skarpetkami.
— Razem z dyskiem z backupem?
— Nie, panie Grzesiu. W drugiej szufladzie!
— ...
— Przecież mówił pan, żeby przechowywać osobno!
— Pani Agnieszko, chodziło też o odpowiednie zabezpieczenie dostępu.
— To ja do tej szuflady nikogo nie wpuszczam. Nawet kierownika.

🤣🤣🤣

Kartka z hasłem nie jest automatycznie katastrofą, jeśli jest odpowiednio zabezpieczona, a hasło długie i unikalne. Ale hasło przyklejone do monitora w dostępnym pomieszczeniu albo zapisane w publicznym arkuszu to proszenie się o kłopoty. Można wykorzystać menedżer haseł, indywidualne konta i MFA, jeśli aplikacja je obsługuje, oraz osobne procedury awaryjnego dostępu.

Istotniejsze od miejsca kartki jest pytanie: czy przypadkowa osoba może uzyskać dostęp do konta i całej bazy? Dostęp do jednego programu nie powinien automatycznie oznaczać pełnych uprawnień administracyjnych w silniku bazy danych.

Rozdział piąty: kierownik pożycza hasło pani Agnieszki

— PANI AGNIESZKO! MUSZĘ NATYCHMIAST ZOBACZYĆ FAKTURĘ!
— Zaraz panu pokażę.
— NIE MAM CZASU! PROSZĘ MI DAĆ HASŁO!
— Ale pan Grzesiu zabronił.
— TO JA JESTEM KIEROWNIKIEM!
— No dobrze...
Dwie godziny później.
— PANIE GRZESIU! KTO USUNĄŁ TRZYSTA FAKTUR?!
— W dzienniku widzę konto pani Agnieszki.
— PANI AGNIESZKO!!!
— Ale ja robiłam rozliczenie w drugim pokoju!
— Panie kierowniku, kto rano pożyczał jej hasło?
— PANIE GRZESIU, PROSZĘ NIE ZBACZAĆ Z TEMATU!

🤣🤣🤣

Każda osoba powinna mieć własną tożsamość i uprawnienia dopasowane do pracy. Kierownikowi, który potrzebuje tylko przeglądać raporty, nie trzeba dawać dostępu do kasowania faktur ani administracji bazą. Księgowa może edytować księgowania, ale nie musi zarządzać całym serwerem. Administrator techniczny też powinien używać podwyższonych uprawnień tylko wtedy, gdy to konieczne.

Wspólne hasło całego działu utrudnia rozliczalność. Jeśli program łączy się z bazą jednym kontem technicznym, zwykły log silnika może pokazywać wyłącznie nazwę typu app_user. Wtedy do ustalenia faktycznej osoby potrzebne są wiarygodne logi aplikacji i właściwie zaprojektowany audyt.

— PANIE GRZESIU! WSZYSTKO WYKONAŁ app_user!
— To konto aplikacji.
— TO PROSZĘ GO NATYCHMIAST ZWOLNIĆ!

Rozdział szósty: arkusik w Google i tajemnica dla każdego z linkiem

— PANIE GRZESIU! — woła pani Agnieszka. — ZROBIŁAM ZESTAWIENIE DLA KIEROWNIKA!
— Gdzie?
— W Arkuszach Google. Bardzo wygodne, bo działa na telefonie!
— A kto ma dostęp?
— Każdy z linkiem.
— Czy w środku są prywatne dane pracowników?
— No są, przecież kierownik chciał je zobaczyć.
— A gdzie jest link?
— Wysłałam wszystkim. Ale spokojnie, panie Grzesiu, link jest bardzo długi!
— ...
— To dobrze?
— Najpierw ograniczymy dostęp.

🤣🤣🤣

Arkusze Google, Excel w chmurze czy współdzielone dokumenty nie są z definicji niebezpieczne. Potrafią świetnie służyć do współpracy, mają konta, historię zmian i mechanizmy udostępniania. Nie wolno jednak mylić wygody z pełną kontrolą nad poufnymi danymi. Ustawienie „każdy z linkiem” oznacza inną grupę odbiorców niż „tylko konkretne upoważnione osoby”.

Nie zapisujemy tam bezrefleksyjnie haseł, tokenów, kluczy API, kopii dokumentów tożsamości, danych medycznych, pełnych zestawień kadrowych czy wrażliwych informacji finansowych. Nie chodzi o absolutny zakaz korzystania z konkretnego dostawcy, ale o ocenę, czy usługa, umowy, konfiguracja, podstawa przetwarzania danych, uprawnienia i retencja są odpowiednie. Czasami wystarczy mniej danych albo zestawienie zagregowane zamiast pełnej listy osób.

Rozdział siódmy: excelik awansuje na system krytyczny

— PANI AGNIESZKO! DLACZEGO NIE MOŻEMY PRACOWAĆ NA TYM SAMYM EXCELU WSZYSCY NARAZ?!
— Bo wczoraj poprawiłam adres klienta, a pan nadpisał plik starszą wersją.
— TO NIECH PANI NIE POPRAWIA, JAK JA POPRAWIAM!
— To może dać nam pan grafik poprawiania?
— PANI AGNIESZKO! TO MA BYĆ NOWOCZESNY SYSTEM!
— To może pan Grzesiu sprawdzi, czy narzędzie obsługuje wspólną pracę i historię zmian?
— PANIE GRZESIU! PROSZĘ ZROBIĆ, ŻEBY EXCEL BYŁ BAZĄ DANYCH, ALE NIC NIE KOSZTOWAŁ!

🤣🤣

Arkusz z kilkudziesięcioma pozycjami może być znakomitym rozwiązaniem. Kłopoty zaczynają się, gdy staje się centralną bazą firmy: wiele osób modyfikuje te same rekordy, formuły się rozjeżdżają, uprawnienia obejmują cały plik, a operacje nie są transakcyjne. Współczesne usługi arkuszowe potrafią wspólną edycję i historię zmian, ale to nadal nie jest automatycznie ten sam model integralności co prawidłowo zaprojektowana baza transakcyjna.

Warto rozróżniać zwykły współdzielony plik na dysku, arkusz z funkcją współtworzenia w chmurze i aplikację działającą na serwerze baz danych. Nie każdy arkusz jest zły. Zły jest brak świadomości ograniczeń narzędzia, któremu powierzono istotne informacje.

Rozdział ósmy: jedna faktura, trzy kwoty i znikający prąd

— PANIE GRZESIU! — woła Agnieszka. — Klient zapłacił fakturę, ale komputer dalej pokazuje dług!
— A płatność?
— Jest zapisana.
— A saldo klienta?
— Stare.
— A status faktury?
— „Nieopłacona”.
— TO NIECH KLIENT ZAPŁACI JESZCZE RAZ! — zarządza kierownik.
— Panie kierowniku, klient zapłacił. Trzeba naprawić spójność danych, nie jego portfel.
— TO DLACZEGO KOMPUTER NIE UMIE DODAWAĆ?!

🤣🤣

W bazach obsługujących transakcje można grupować powiązane operacje. COMMIT zatwierdza poprawnie zakończoną transakcję, a ROLLBACK wycofuje zmiany niezatwierdzonej transakcji; nie jest magicznym cofnięciem dowolnej operacji sprzed miesiąca. Zasady ACID opisują własności transakcji, między innymi atomowość i trwałość, zależne od konkretnego silnika oraz konfiguracji.

Ograniczenia integralności mogą pilnować np. istnienia wskazanego klienta czy unikalnego numeru dokumentu. Nie zastępują one poprawnych reguł księgowych i dobrze napisanej aplikacji. Baza może być technicznie spójna, a mimo to przechowywać błędną kwotę, jeśli ktoś ją poprawnie, lecz omyłkowo wprowadził.

Rozdział dziewiąty: kopia pliku bazy z działającego programu

— PANI AGNIESZKO, ZROBIŁA PANI BACKUP? — pyta Grzesiu.
— Oczywiście! Skopiowałam folder programu na pendrive.
— Podczas pracy?
— Tak. Żeby nie przeszkadzać księgowości.
— A baza jest plikowa czy serwerowa?
— Zielona ikonka. Panie Grzesiu, ja naprawdę nie wiem.
— Sprawdzimy, czy program ma własną funkcję kopii albo czy potrzebny jest backup zgodny z silnikiem.
— To ja może nie będę usuwać starego dysku?
— Pani Agnieszko, to bardzo dobry pomysł.

🤣🤣

Zwykłe kopiowanie plików działającej bazy nie musi tworzyć poprawnej kopii. Bazy mogą trzymać część zmian w pamięci i dziennikach, blokować pliki lub wymagać spójnego obrazu z określonego momentu. SQLite może używać osobnych plików dziennika WAL, Access ma swoje zasady pracy współdzielonej, a MySQL, PostgreSQL i SQL Server oferują mechanizmy kopii dostosowane do swoich silników.

Właściwa metoda zależy od aplikacji i konfiguracji. Niekiedy potrzebny jest backup logiczny, innym razem fizyczny, migawka ze spójnością aplikacyjną albo bezpieczne zatrzymanie usługi. Nie kopiuje się na ślepo losowego katalogu i nie uznaje samego istnienia pliku za dowód możliwości odtworzenia.

Rozdział dziesiąty: replika jest bardzo posłuszna

— PANIE GRZESIU! MAMY DRUGI SERWER BAZY!
— Tak, to replika.
— WIĘC NIC JUŻ NIE ZGINIE!
— Replika pomaga przy pewnych awariach i obciążeniach, ale nie zastępuje kopii historycznej.
— A GDYBYM USUNĄŁ FAKTURY?
— Usunięcie może zostać powielone.
— NA DRUGIM SERWERZE TEŻ?!
— Tak, zgodnie z zasadami replikacji.
— TO PO CO KUPIŁEM DRUGI SERWER, SKORO ON POWTARZA BŁĘDY PIERWSZEGO?!

🤣🤣

Replikacja i wysoka dostępność to nie to samo co backup. Drugi serwer może szybko przejąć zadania po awarii sprzętu, ale równie sprawnie powielić błędne polecenie, uszkodzenie logiczne lub niepożądaną zmianę. Kopie historyczne, odpowiednia retencja i niezależne uprawnienia tworzą inną warstwę ochrony.

Rozdział jedenasty: hasła i sekrety nie powinny podróżować z eksportem

— PANI AGNIESZKO, GDZIE JEST RAPORT? — pyta kierownik.
— Wysłałam go panu mailem.
— DOSKONALE!
— A skąd pani wzięła dane? — pyta Grzesiu.
— Wyeksportowałam całą bazę, żeby niczego nie pominąć.
— Całą?
— Tak. A potem usunęłam niepotrzebne kolumny w swoim Excelu.
— Ale wcześniej wysłała pani oryginał?
— ...
— ...
— PANIE GRZESIU, CZY MOGĘ COFNĄĆ INTERNET?!

🤣🤣

Nawet najlepiej chroniona baza może utracić poufność po niekontrolowanym eksporcie do CSV, XLSX, PDF, załącznika mailowego lub prywatnej chmury. Konta, role i szyfrowanie na serwerze nie zabezpieczają automatycznie kopii, którą ktoś pobierze i udostępni dalej.

Warto ograniczać eksporty do niezbędnych pól, pilnować odbiorców, zabezpieczać pliki, stosować rozsądną retencję i ustalić, kto może wynosić dane z aplikacji. Taki raport może być równie poufny jak baza źródłowa.

Rozdział dwunasty: nie wszystko, co możemy zapisać, powinniśmy przechowywać

— PANI AGNIESZKO! PRZECHOWUJEMY WSZYSTKIE DANE KLIENTÓW OD 1997 ROKU!
— A po co, panie kierowniku?
— BO MOGĄ SIĘ PRZYDAĆ!
— Do czego?
— ...
— Panie kierowniku?
— PANI AGNIESZKO, PROSZĘ NIE ZADAWAĆ MI PYTAŃ, NA KTÓRE NIE MAM RUBRYKI!

🤣🤣

Jedną z ważnych zasad ochrony danych jest minimalizacja: zbieramy i przechowujemy to, co rzeczywiście potrzebne do konkretnego celu. Nie oznacza to automatycznego kasowania starych ksiąg i dokumentów: wiele kategorii danych ma ustawowe okresy przechowywania, a obowiązki różnią się zależnie od dokumentów i przepisów.

Za to prywatna kopia pełnej bazy klientów „bo może kiedyś się przyda” nie staje się bezpieczna tylko dlatego, że nikt o niej nie pamięta. Trzeba wiedzieć, gdzie istnieją eksporty, kto ma do nich dostęp, kiedy wolno je usunąć i co dzieje się z kopiami zapasowymi.

Rozdział trzynasty: awaria po aktualizacji i baza, której nikt nie umie otworzyć

— PANI AGNIESZKO! ZAKTUALIZOWAŁEM PROGRAM KSIĘGOWY!
— A kopia bazy przed aktualizacją?
— PRZECIEŻ PROGRAM BYŁ NOWY!
— A dane?
— STARE!
— Czy aktualizacja zmieniła ich format?
— PROGRAM MÓWI „KONWERSJA ZAKOŃCZONA”!
— A stara wersja programu już nie otwiera bazy — mówi Grzesiu.
— TO PROSZĘ ODINSTALOWAĆ KONWERSJĘ!
— To nie jest osobny program.
— TO NIECH PAN NAPISZE REKLAMACJĘ DO PRZYSZŁOŚCI!

🤣🤣

Aktualizacje oprogramowania mogą zmieniać strukturę bazy, format plików i wymagania środowiska. Powrót do starej wersji programu nie musi odwracać migracji danych. Przed większymi zmianami warto sprawdzić wymagania, wykonać właściwą kopię, przetestować procedurę odtworzenia i rozumieć, jak wygląda cofnięcie wdrożenia.

Archiwa wieloletnie mają jeszcze inny problem: za kilka lub kilkanaście lat może brakować kompatybilnego programu, licencji, sterownika albo systemu operacyjnego. Dlatego warto planować długoterminową czytelność danych, w tym udokumentowane eksporty do odpowiednich formatów i zachowanie możliwości uruchomienia niezbędnego środowiska — bez traktowania samego CSV jako kompletnego zastępstwa wszystkich funkcji bazy.

Rozdział czternasty: pani Agnieszka i jej zawodowe szczęście

W księgowości rozlega się alarm.

— PANIE GRZESIU! NIE MOGĘ OTWORZYĆ ROZLICZEŃ!
— Co się stało?
— Kierownik przeniósł program, potem zaktualizował komputer, a później powiedział, że nie potrzebujemy starego serwera.
— Czy pani coś zmieniała?
— Nie. Pamiętałam, jak pan mówił: „jak nie wiesz, nie klikaj”.
— A backup?
— Jest ten, który pan robi. I mam notatkę z numerem telefonu do pana.
— Doskonale. A gdzie notatka?
— W szufladzie.
— Pod skarpetkami?
— Nie. W drugiej!

🤣🤣🤣

Pani Agnieszka nie musi samodzielnie naprawiać serwera SQL, znać plików dziennika ani wiedzieć, czym różni się SQLite od PostgreSQL-a. Wystarczy, że wie, kiedy zatrzymać pracę, jak zgłosić problem, kogo powiadomić i dlaczego nie należy zgadywać na produkcyjnych danych. Znajomość własnych granic kompetencji jest umiejętnością, a nie słabością.

Pan Grzesiu z kolei odpowiada za sprawdzenie kopii, ograniczenie uprawnień, odpowiednią metodę odzyskiwania i dokumentację. Szczęście pani Agnieszki bywa urocze, ale nie zastępuje zaplanowanego bezpieczeństwa.

Rozdział piętnasty: czy kopia naprawdę pozwoli wrócić do pracy?

— PANIE GRZESIU! MAMY BACKUP BAZY! — cieszy się kierownik.
— Bardzo dobrze. A jak go odtworzymy?
— DWUKLIKIEM!
— A jeśli potrzebujemy starszej wersji programu, licencji, konfiguracji i kluczy?
— ...
— A jeśli kopia wymaga dzienników transakcyjnych?
— ...
— Panie kierowniku?
— PANI AGNIESZKO! GDZIE SĄ TE PANI SKARPETKI?!

🤣🤣

Poprawna kopia bazy to nie zawsze jeden plik. Do odtworzenia mogą być potrzebne: odpowiedni silnik lub aplikacja, wersja schematu, konta, konfiguracja, niezbędne dzienniki, klucze i sprawdzony sposób uruchomienia systemu. W części rozwiązań można odtworzyć stan do konkretnego momentu — PITR — jeśli przygotowano właściwe kopie i komplet dzienników.

Ważne są okresowe testy: czy dokumenty są kompletne, czy rozliczenia się zgadzają, czy użytkownicy mają właściwe uprawnienia i czy aplikacja rzeczywiście działa. Backup bazy bez możliwości przywrócenia użytecznej pracy to niepełny plan ratunkowy.

Finał: awans skarpetek na dział bezpieczeństwa

Koniec miesiąca. Pani Agnieszka zamyka rozliczenia. Pan Grzesiu potwierdza wykonanie i sprawdzenie kopii. Kierownik wpada do pokoju z triumfalną miną.

— PANI AGNIESZKO! MAMY PROFESJONALNY SERWER BAZ DANYCH!
— To bardzo dobrze.
— INDYWIDUALNE KONTA!
— Świetnie.
— HISTORIĘ ZMIAN!
— Cudownie.
— BACKUPY I TESTY ODTWARZANIA!
— Pan Grzesiu się napracował.
— WIĘC MOŻE PANI WYRZUCIĆ TEN STARY DYSK SPOD SKARPETEK!
— Nie, panie kierowniku.
— DLACZEGO?!
— Bo ja lubię wiedzieć, że mamy więcej niż jedną drogę ratunku. A pan Grzesiu ma plan, kiedy ten dysk wymienić.
— PANI AGNIESZKO, PANI MNIE NIE SZANUJE JAKO KIEROWNIKA!
— Szanuję. Ale dane trochę bardziej.

🤣🤣🤣🤣

Zapamiętaj: bezpieczeństwo bazy nie zależy wyłącznie od tego, czy nazywa się MySQL, PostgreSQL, MSSQL, Access, SQLite, Pervasive, Excel czy Arkusze Google. Zależy od rzeczywistych uprawnień, spójności danych, sposobu udostępniania, poprawnych kopii i możliwości ich odtworzenia. Najlepszy system to taki, który chroni informacje, a nie tylko wygląda profesjonalnie.

Pani księgowa Agnieszka wróciła do faktur. Pan Grzesiu wrócił do serwerów. Pan Franek, przeniesiony do transportu po incydencie z kartką na szybie samochodu, otrzymał nowe polecenie: nie opisywać przewożonych dysków wielkimi literami. Kierownik zamówił pieczątkę „BAZA ZABEZPIECZONA”.