SQL Server 2022 Ledger i Temporal Tables (tabele temporalne, system-versioned) to dwie wbudowane technologie Microsoft SQL Server służące do przechowywania historii zmian danych — ale różnią się fundamentalnie celem, mechanizmem działania i gwarancjami bezpieczeństwa. Temporal Tables (dostępne od SQL Server 2016) odpowiadają na pytanie „jaka była wartość tego rekordu w danym momencie?”, natomiast Ledger (wprowadzony w SQL Server 2022) dodaje kryptograficzny dowód, że „dane nie zostały sfałszowane od momentu ich zapisania” — również przez administratora bazy.
W skrócie
- Temporal Tables (od SQL Server 2016) — automatyczne, systemowe wersjonowanie każdej zmiany wiersza z użyciem kolumn
ValidFrom/ValidTo- Ledger (od SQL Server 2022) — kryptograficzna ochrona przed manipulacją (tamper-evidence) oparta na drzewie Merkle i łańcuchu bloków (blockchain), z funkcją weryfikacji integralności
- Temporal Tables chronią przed utratą danych historycznych; Ledger chroni przed ich nieautoryzowaną modyfikacją
- Obie technologie można stosować równolegle — Ledger wykorzystuje wewnętrznie mechanizm zbliżony do Temporal Tables, ale dodaje warstwę kryptograficzną
- Temporal Tables są darmowe we wszystkich edycjach SQL Server; Ledger wymaga SQL Server 2022 (dowolna edycja, również Express)
- Kluczowa różnica: Temporal Tables są dla audytu biznesowego; Ledger jest dla dowodowej wiarygodności (compliance, audyt zewnętrzny, blockchain)
Werdykt — co wybrać?
| Kryterium | Wybierz Temporal Tables | Wybierz Ledger |
|---|---|---|
| Potrzebujesz odtworzyć stan danych na konkretną datę | ✅ | ⚠ (częściowo, przez ledger view) |
| Potrzebujesz udowodnić audytorowi zewnętrznemu, że dane nie były modyfikowane | ❌ | ✅ |
| Obawiasz się, że DBA lub administrator systemu może manipulować danymi | ❌ | ✅ |
Chcesz prostoty — SYSTEM_VERSIONING = ON w istniejącej tabeli | ✅ | ⚠ (trzeba utworzyć tabelę od nowa jako ledgerową) |
| Wymagania compliance: SOX, HIPAA, GDPR, EU Digital Operational Resilience Act | ⚠ (częściowo) | ✅ |
Potrzebujesz kwerend FOR SYSTEM_TIME AS OF, BETWEEN, CONTAINED IN | ✅ | ⚠ (ograniczone do ledger view) |
Twoja aplikacja intensywnie korzysta z TRUNCATE, CASCADE, INSTEAD OF triggerów | ✅ | ❌ (ograniczenia ledger) |
| Chcesz zabezpieczyć dane przed modyfikacją przez wysoko uprzywilejowanych użytkowników | ❌ | ✅ |
Porównanie techniczne — tabela obok siebie
| Cecha | Temporal Tables (od SQL 2016) | Ledger (od SQL 2022) |
|---|---|---|
| Wersja SQL Server | 2016 i nowsze | 2022 i nowsze |
| Cel główny | Historia zmian (audyt biznesowy) | Niezaprzeczalność i odporność na manipulację (tamper-evidence) |
| Mechanizm działania | System automatycznie zapisuje starą wersję wiersza w tabeli historii | Kryptograficzny łańcuch bloków (Merkle tree + SHA-256) łączący transakcje |
| Tabela historii | Jawna, dostępna do odczytu | Historia przechowywana automatycznie, również chroniona kryptograficznie |
| Ochrona przed DBA | ❌ — DBA może zmodyfikować tabelę historii | ✅ — każda modyfikacja zostanie wykryta podczas weryfikacji |
| Weryfikacja integralności | Brak — dane można zmodyfikować bez śladu (z odpowiednimi uprawnieniami) | sys.sp_verify_database_ledger — kryptograficzna walidacja całości bazy |
| Database digest | Nie dotyczy | Tak — skrót (hash) bazy publikowany do zewnętrznego, niezmienialnego magazynu |
| Typy tabel | Jeden typ: system-versioned | Dwa typy: updatable ledger (UPDATE/DELETE dozwolone) i append-only ledger (tylko INSERT) |
| Kolumny okresowe | ValidFrom (period start), ValidTo (period end) — datetime2 | Kolumny ledger_start_transaction_id, ledger_end_transaction_id (generowane przez system) |
| Kwerendy punktu w czasie | FOR SYSTEM_TIME AS OF, BETWEEN, FROM ... TO, CONTAINED IN, ALL | Ledger view — kwerendy łączące bieżącą tabelę z historią |
| Wydajność (INSERT/UPDATE) | Minimalny narzut (dodatkowy INSERT do tabeli historii) | Wyższy narzut — hashowanie SHA-256 dla każdej transakcji |
| Maks. rozmiar danych | Ograniczony tylko pojemnością dysku | To samo, ale historia i hashe zwiększają zużycie przestrzeni o ~20-40% |
| TRUNCATE TABLE | Niedozwolone przy SYSTEM_VERSIONING = ON | Niedozwolone na tabelach ledger |
| CASCADE (FK) | Niedozwolone przy kluczach obcych z tabeli temporalnej | Niedozwolone |
| INSTEAD OF triggery | Niedozwolone | Niedozwolone |
Czym są Temporal Tables (tabele temporalne)
Temporal Tables, dostępne od SQL Server 2016, to mechanizm automatycznego wersjonowania danych — każda zmiana wiersza w tabeli głównej (current table) powoduje zapisanie poprzedniej wersji w równoległej tabeli historii (history table). System zarządza tym transparentnie: wystarczy dodać dwie kolumny okresowe typu datetime2 (ValidFrom / ValidTo) i włączyć SYSTEM_VERSIONING = ON.
Jak działa
- INSERT:
ValidFromustawiane na czas rozpoczęcia transakcji (UTC),ValidTona9999-12-31(wiersz „otwarty”) - UPDATE: poprzednia wersja wiersza trafia do tabeli historii z
ValidTo= czas transakcji, nowa wersja w tabeli bieżącej dostaje nowyValidFrom - DELETE: cały wiersz przenoszony do tabeli historii,
ValidTozamykane czasem transakcji
Główne zastosowania
- Audyt zmian biznesowych (kto, kiedy, jaką wartość zmienił)
- Odtwarzanie stanu danych na dowolny moment w przeszłości (
FOR SYSTEM_TIME AS OF '2025-06-01') - Obliczanie trendów w czasie (np. zmiana stanu magazynowego dzień po dniu)
- Odtwarzanie danych po przypadkowym
UPDATEbezWHERE(recover from application error) - Slowly Changing Dimensions (SCD) w hurtowniach danych
Ograniczenia
- Administrator z uprawnieniami
sysadminmoże ręcznie zmodyfikować tabelę historii — brak ochrony kryptograficznej - Brak możliwości udowodnienia audytorowi zewnętrznemu, że dane nie były zmieniane po fakcie
- Temporal Tables nie są odporne na atak na poziomie plików bazy danych (mdf/ldf)
Czym jest Ledger w SQL Server 2022
SQL Server Ledger to technologia tamper-evidence (dowodowej odporności na manipulację) wprowadzona w SQL Server 2022. W przeciwieństwie do Temporal Tables, których celem jest wygoda dostępu do historii, Ledger ma gwarantować, że każda nieautoryzowana modyfikacja danych zostanie wykryta — nawet jeśli dokona jej administrator bazy (DBA), administrator systemu czy administrator chmury.
Jak działa kryptograficznie
- Każda transakcja modyfikująca tabele ledger jest hashowana algorytmem SHA-256 z użyciem struktury drzewa Merkle (Merkle tree).
- Transakcje są łączone kryptograficznie w bloki — każdy blok zawiera skrót (root hash) wszystkich transakcji w bloku oraz skrót poprzedniego bloku, tworząc łańcuch bloków (blockchain).
- Skrót najnowszego bloku w bazie to database digest — może być okresowo eksportowany i przechowywany w zewnętrznym, niezmienialnym magazynie (np. Azure Immutable Blob Storage, Azure Confidential Ledger, WORM).
- Weryfikacja polega na ponownym przeliczeniu hashy na podstawie aktualnego stanu tabel i porównaniu z zapisanymi wcześniej digestami. Jakakolwiek rozbieżność = dowód manipulacji.
Dwa typy tabel Ledger
- Updatable ledger tables: dopuszczają UPDATE i DELETE — każda poprzednia wersja wiersza trafia do automatycznej tabeli historii (podobnie jak w Temporal Tables), ale jest również chroniona kryptograficznie
- Append-only ledger tables: dopuszczają wyłącznie INSERT — idealne dla logów bezpieczeństwa (SIEM), rejestrów transakcji finansowych, ścieżek audytu. Nie mają tabeli historii (nie ma czego zapisywać)
Weryfikacja integralności
Do walidacji służy procedura składowana sys.sp_verify_database_ledger. Proces pobiera wcześniej opublikowany database digest, przelicza hashe na podstawie bieżącej zawartości wszystkich tabel ledger i porównuje wyniki. Jeśli wykryje rozbieżność, raportuje szczegółowo, które transakcje/wiersze zostały naruszone.
Kiedy wybrać Temporal Tables, a kiedy Ledger
Wybierz Temporal Tables, gdy:
- Potrzebujesz prostego mechanizmu audytu zmian w aplikacji biznesowej (ERP, CRM)
- Chcesz móc zapytać
AS OFo stan na konkretny moment w czasie z prostym SQL-em - Używasz SQL Server 2016, 2017 lub 2019 (brak dostępu do Ledger)
- Nie masz wymogu zewnętrznej atestacji integralności danych
- Zależy Ci na minimalnym narzucie wydajnościowym
Wybierz Ledger, gdy:
- Podlegasz regulacjom wymagającym kryptograficznego dowodu integralności (SOX, HIPAA, GDPR Art. 5(f), DORA w UE)
- Chcesz udowodnić audytorowi, że dane nie były modyfikowane przez nikogo — włącznie z DBA
- Budujesz wielostronny proces biznesowy (supply chain), gdzie różne organizacje muszą ufać centralnej bazie danych
- Potrzebujesz trusted off-chain storage dla aplikacji blockchainowych
- Przechowujesz dane o krytycznym znaczeniu: rejestry finansowe, medyczne, logi bezpieczeństwa
Możesz stosować obie technologie jednocześnie
W praktyce wiele firm używa Temporal Tables w starszych bazach (2016–2019) i wdraża Ledger w nowych komponentach na SQL Server 2022. Updatable ledger table wewnętrznie przypomina tabelę temporalną — musisz jednak utworzyć ją od początku jako ledgerową; nie można przekonwertować istniejącej tabeli temporalnej na ledgerową.
Częste pytania
Czy Ledger zastępuje Temporal Tables?
Nie — to technologie komplementarne. Temporal Tables dostarczają wygodnego dostępu do historii w celach analitycznych i biznesowych, Ledger dostarcza kryptograficznej gwarancji integralności. Updatable ledger table wewnętrznie używa mechanizmu podobnego do system-versioning, ale nie oferuje składni FOR SYSTEM_TIME w takim samym zakresie jak Temporal Tables.
Czy Ledger działa w SQL Server Express?
Tak — Ledger jest dostępny we wszystkich edycjach SQL Server 2022, włącznie z bezpłatną edycją Express. Ograniczeniem Express może być rozmiar bazy (10 GB) przy intensywnym użyciu tabel ledgerowych, które zużywają dodatkową przestrzeń na historię i struktury kryptograficzne.
Czy mogę przekonwertować istniejącą tabelę temporalną na tabelę ledger?
Nie. Nie ma możliwości konwersji istniejącej tabeli na ledgerową. Tabela musi zostać utworzona jako ledgerowa (LEDGER = ON) od początku. Możesz natomiast utworzyć nową tabelę ledgerową i migrować do niej dane, zachowując starą tabelę temporalną jako archiwum.
Jaki jest narzut wydajnościowy Ledger względem Temporal Tables?
Operacje INSERT i UPDATE na tabelach ledger są wolniejsze o ok. 5–15% w porównaniu do zwykłych tabel temporalnych, ze względu na hashowanie SHA-256 każdej transakcji przez drzewo Merkle. Różnica rośnie przy dużej liczbie współbieżnych transakcji. Dla większości zastosowań biznesowych narzut jest akceptowalny.
Czy mogę wyłączyć Ledger po jego włączeniu?
Nie. Ledger database (bazy skonfigurowanej jako ledger przy tworzeniu) nie można przekonwertować z powrotem na zwykłą bazę danych. Pojedyncza tabela ledgerowa również nie może zostać „cofnięta” do zwykłej tabeli — ta nieodwracalność jest celowa i stanowi część gwarancji integralności.
Czy Temporal Tables i Ledger chronią przed atakiem ransomware?
Częściowo. Temporal Tables pozwolą odtworzyć dane sprzed ataku z tabeli historii — o ile atakujący nie usunął lub nie zmodyfikował również tabeli historii. Ledger ochroni przed nieautoryzowaną modyfikacją (wykryje ją), ale nie zapobiega usunięciu całej bazy danych — przed tym chronią wyłącznie kopie zapasowe (backup) i disaster recovery. Database digest przechowywany poza bazą pozwoli udowodnić, że dane zostały naruszone.
Czy Ledger wymaga Azure, czy działa w pełni on-premises?
Ledger działa w pełni on-premises na SQL Server 2022. Do przechowywania database digest możesz użyć dowolnego magazynu WORM (Write Once Read Many) lub ręcznie eksportować digesty do plików. Azure Blob Storage z polityką immutability ani Azure Confidential Ledger nie są wymagane — to opcjonalne ułatwienia w środowisku chmurowym.
Potrzebujesz SQL Server 2022, aby zacząć pracę z Ledger?
Technologia Ledger wymaga SQL Server 2022 — nie jest dostępna we wcześniejszych wersjach. Jeśli planujesz wdrożenie środowiska deweloperskiego, testowego lub produkcyjnego z SQL Server 2022, w sklepie KluczeSoft znajdziesz legalne licencje Microsoft w atrakcyjnych cenach:
→ SQL Server 2022 Standard — licencje już od kilkuset złotych
KluczeSoft.pl jest niezależnym sprzedawcą oprogramowania Microsoft na zasadach ponownej sprzedaży licencji (zgodnie z orzeczeniem TSUE w sprawie UsedSoft). Nie jesteśmy afiliowani z Microsoft Corporation.
<!-- IL-V1 -->Powiązane artykuły
- Azure SQL vs SQL Server on-premises — porównanie 2026 — Azure SQL Database to najprostsza opcja w rodzinie Azure SQL — pojedyncza baza danych działająca na w pełni zarządzanym, stale aktualizowany.
- Wymagania systemowe — SQL Server 2022 — Wymagania sprzętowe i systemowe Microsoft SQL Server 2022.
- SQL Server Standard vs Enterprise — porównanie edycji, różnice, co wybrać w 2026 — SQL Server Standard to edycja zaprojektowana dla średnich organizacji, działów IT i aplikacji biznesowych, które potrzebują solidnej bazy da.
- Windows Server 2022 Standard vs Datacenter — porównanie edycji, różnice, którą wybrać w 2026 — Windows Server 2022 (build 20348) to serwerowy system operacyjny Microsoftu wydany 18 sierpnia 2021 jako następca Windows Server 2019.
- SQL Server vs MySQL vs PostgreSQL — którą bazę danych wybrać dla firmy w 2026? — SQL Server 2025, wydany w listopadzie 2025, to najnowsza odsłona flagowej bazy Microsoftu.