Question

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)

Answer 1

You should not have foreign keys for each data group table in the event table.

The event table already has an event_id which is in each data group table. So you can get from event to the child tables. Furthermore there will be old rows in the event table that are not in the latest data group table. So you really can’t have a foreign key.

That said, I would wonder whether there is additional structure in the data group tables that can be used to clean up your design. Without knowing anything about what they look like I can’t say. But if there is, consider taking advantage of it! (A schema that changes every month is a pretty bad code smell.)