rejestrowanie zmian w rekordach tabeli dla MSSQL SERVER EXPRESS

Witam,
MSSQL Server w wersji Enterprise, Developer, Enterprise Evaluation ma coś co nazywa się "przechwytywaniem zmian". Jako, że mam do czynienia z SQL Server w wersji Express (i pewnie taka pozostanie) gdzie nie ma mozliwości zastosowania "przechwytywania zmian", którą oferują "większe" wersje SQL Servera mam pytanie jak rozwiązać problem śledzenia zmian w rekordach tabeli w wersji Express.

Czy rozwiązanie z triggerem na insert, update i delete byłoby dobre?
Sprawdziłem i działa (robi insert do tabeli [table_b] gdy są zmiany w tabeli [table_a] ale to dla wartości "testowych").

Jak sensownie pobrać wartości z rekordu wstawianego, modyfikowanego lub usuwanego z tabeli [table_a] i wrzucić je do tabeli [table_b]. Zakładam, że w obu tabelach są takie same pola.

Mam np. tabelę table_a
[id]
,[typ]
,[nazwa]
,[autor]
,[data_utworzenia]

i tabelę table_b o takiej samej strukturze.

tworzę trigger

create trigger tr_changes_in_table_a
[dbo].[table_a]
FOR INSERT, UPDATE, DELETE
AS
BEGIN

INSERT INTO [dbo].[table_b] 
           ([id]
           ,[typ]
           ,[nazwa]
           ,[autor]
           ,[data_utworzenia])

	VALUES(1,'k1','pozycja zamienna',1,GETDATE()); -- tutaj chciałbym wstawić wartości z modyfikowanego rekordu tabeli A
END

Tabele INSERTED i DELETED https://msdn.microsoft.com/pl-pl/library/ms191300(v=sql.110).aspx

gg napisał(a):

Czy rozwiązanie z triggerem na insert, update i delete byłoby dobre?

Zależy jak definiować "dobroć". ;)

Takie rozwiązanie ma pewne wady - jest niezbyt szybkie, spowalnia operacje bazodanowe, trudno się utrzymuje (każda zmiana struktury tabeli oznacza konieczność naniesienia poprawki w tabeli audytowej oraz wyzwalaczu). Ma też jedną zaletę - nieważne w jaki sposób dane zostaną zmienione (przez jaką aplikację albo ręcznie przez użytkownika), to informacja o tym się zapisze.
Ale wszystko zależy od tego, co chcesz osiągnąć. Jeśli źródłem zmian może być tylko jedna aplikacja, to może być lepiej dodać taką logikę do aplikacji.

Osiągnąć chcę tylko jedno - chcę w bazie, w tabelach z danymi historycznymi gromadzić informacje o zmianach w tabelach źródłowych.

Danych rejestrowanych w ten sposób nie będzie wiele, w większości dane w tabelach będą wprowadzone raz i system będzie z nich korzystać. Zakładam, że będzie kilkadziesiąt prostych tabel, z których tylko kilka/kilkanaście będzie mieć zmieniane dane parę razy na godzinę.

Istotny jest sposób wprowadzania danych - czy będzie to jedna aplikacja, czy wiele, czy ktoś będzie to robił przez edytor SQL czy na pewno nie.
Ważne jest też jak często będzie się zmieniała struktura tabel.