sql – How do you handle database normalization design for optional columns?

sql – How do you handle database normalization design for optional columns?

I think going with option 2 is not bad, even if database will have milions of rows. You will only need a index on SensiorId and Timestamp.

I can think of one different design containing two tables:

**SensorRead**
Id (PK)
SensorId
Timestamp

**SensorData**
Id(PK)
ReadId(FK)
Value
DataType

If you will query that schema for values for given SensorId and timestamp, then it will result in the join between 10 rows (assuming the sensor reads 10 data points). So the cost is almost none.

Aside from the question itself- Im not sure, that having multiple columns as PKs will work good with entity framework… Never tried it, but if you decide to go that way do some research about this.

sql – How do you handle database normalization design for optional columns?

Leave a Reply

Your email address will not be published.