Our database is part of a (specialized) desktop application. 
The primary goal is to keep data about certain **events**.

**Events** happen every few minutes.

The data collected about **events** changes frequently with new data groups being added in and old ones swapped out almost monthly (the data comes in definite groups). 

I have to put together a database to track the events. A first stab at that might be to simply have a single big table where each row is an event and that is basically what our data looks like, but this seems undesirable because of our constantly changing groups of data (i.e. the number of columns would either keep growing perpetually or we would constantly having this months database incompatible with last months database - ugh!). Because of this I am leadning toward the following even though it creates circular references. (But maybe this is a stupid idea)

Create tables like

Table Events  

Table Group of the Month 1  

Table Group of the Month 2  

... 

Table Events has:  

A primary key whose deletion cascade to delete rows with foreign keys referencing it  

A nullable foreighn key for each data group table 

Each data group table has:  

A primary key, whose deletion cascades to null out foreign keys referencing it  

Columns for the data in that group  

A non-nullable foreign key back to the event 

This still leaves you with a growing, changing Event Table (as you need to add new foreign key columns for each new data group), just much less drastically. However it seems more modular to me than one giant table. Is this a good solution to this situation? If not, what is?

Any suggestions?

P.S. We are using SQL Express or SQL Compact (we are currently experimenting with which one suits us best)