Korištenje RDBMS-a kao skladišta izvora događaja

Ako bih koristio RDBMS (npr. SQL Server) za pohranu podataka o izvorima događaja, kako bi shema mogla izgledati?

Vidio sam nekoliko varijacija o kojima se govori u apstraktnom smislu, ali ništa konkretno.

Na primjer, recimo da netko ima entitet "Proizvod", a promjene na tom proizvodu mogu se pojaviti u obliku: cijena, cijena i opis. Zbunjen sam oko toga da li bih:

1. imao tablicu "ProductEvent" koja sadrži sva polja za proizvod, pri čemu svaka promjena znači novi zapis u toj tablici, plus "ko, šta, gdje, zašto, kada i kako "prema potrebi. Kada se promijene trošak, cijena ili opis, dodaje se cijeli novi red koji predstavlja Proizvod.
2. Spremite cijenu, cijenu i opis proizvoda u zasebne tablice spojene u tablicu proizvoda s odnosom stranog ključa. Kada se pojave promjene u tim svojstvima, napišite nove retke s WWWWWH po potrebi.
3. Spremite WWWWWH, plus serializirani objekt koji predstavlja događaj, u tabelu "ProductEvent", što znači da sam događaj mora biti učitan, deserializiran i ponovno Reproducirano u mojem kodu aplikacije kako bih ponovno izgradio stanje aplikacije za određeni proizvod.

Posebno me brine opcija 2 iznad. U krajnjem slučaju, tablica proizvoda bila bi gotovo jedna tablica po svojstvu, a za učitavanje stanja aplikacije za dati proizvod bilo bi potrebno učitavanje svih događaja za taj proizvod iz svake tablice događaja proizvoda. Ova eksplozija stola mi miriše pogrešno.

Siguran sam da "ovisi", i premda ne postoji jedinstveni "točan odgovor", pokušavam steći osjećaj što je prihvatljivo, a što potpuno neprihvatljivo . Također sam svjestan da ovdje može pomoći NoSQL, gdje bi se događaji mogli pohraniti prema agregatnom korijenu, što znači samo jedan zahtjev bazi podataka da bi se događaji iz njih obnovili, ali ne koristimo NoSQL db u trenutak, pa se osjećam oko alternativa.