patternMinor
I have this two models, which one is better?
Viewed 0 times
thisbettertwoonewhichmodelshave
Problem
what is a better design??
Model 1:
Model 2:
(there are other tables too, like machine and client)
all types are previusly defined, ex:
there is only 22 types defined, but types can grow in the future.
the problem is not all MachID have all the types.
If i do the model 2 a lot of fields will have null.
All i have to do is store these data and display graphics per MachID.
And to make graphs, i only need time vs type. so i can make sql selects to get tables like this
and graph, but getting this is more difficult with Model 1.
thanks for your help :)
ps:
every month i get like 15000 records average per MachID.
and sorry for my bad english
Model 1:
+------+ +--------+
| type |-|--+ | Data |
+------+ | +--------+
| id | | | Mach ID|
| type | | | Time |
| len | +----<| type ID|
+------+ | data | (binary max 8)
+--------+Model 2:
+---------+
| Data |
+---------+
| Mach ID |
| Time |
| Type_1 |
| Type_2 |
| ... |
| Type_n |
+---------+(there are other tables too, like machine and client)
all types are previusly defined, ex:
- id 08 is the temperature1 and its a float 4 bytes.
- id 16 is a sensor and its an int 4 bytes.
- id 125 is status 2 bytes.
there is only 22 types defined, but types can grow in the future.
the problem is not all MachID have all the types.
If i do the model 2 a lot of fields will have null.
All i have to do is store these data and display graphics per MachID.
And to make graphs, i only need time vs type. so i can make sql selects to get tables like this
+------+--------+--------+-----+--------+
| Time | type_1 | type_2 | ... | type_n |
+------+--------+--------+-----+--------+
| | | | | |and graph, but getting this is more difficult with Model 1.
thanks for your help :)
ps:
every month i get like 15000 records average per MachID.
and sorry for my bad english
Solution
I would use your second model. The first might be more compact, but would require constantly
The second model looks denormalized at first, but if I understand your model right it's really not. You're not really packing 22 records into one, rather you're storing reports each of which may have up to 22 distinct strongly-types measurements. Some reports do not have every measurement, and that's fine.
CASTing your data; the second will have many NULLs, but they take up little space.The second model looks denormalized at first, but if I understand your model right it's really not. You're not really packing 22 records into one, rather you're storing reports each of which may have up to 22 distinct strongly-types measurements. Some reports do not have every measurement, and that's fine.
Context
StackExchange Database Administrators Q#78160, answer score: 2
Revisions (0)
No revisions yet.