TConnolly
Lifetime Supporting Member
Not a DB guru myself, so I'm wondering if I'm going about this the right way.
I'm setting up a recipe database for a process that will contain a setpoint profile. The setpoint profile will have a variable number of setpoint segments (1 to 30), so it doesn't lend itself well to a single table. The single table approach would have 368 columns.
I was thinking of using two tables. The first table would have the following columns
The second table will have the following columns
I was going to query the first table by the profile number, which will return just one record. Querying the second table will return a variable number of records, one for each segment, which I will query ordered by segment number.
Is this a good DB design? Or is there a better way to build the schema, maybe a relational table or some other way?
I'm setting up a recipe database for a process that will contain a setpoint profile. The setpoint profile will have a variable number of setpoint segments (1 to 30), so it doesn't lend itself well to a single table. The single table approach would have 368 columns.
I was thinking of using two tables. The first table would have the following columns
- Profile_Number (int) unique primary key
- Profile_Name varchar40
- High_Limit (int)
- Number_Of_Segments (int) might not be necessary.
- plus a couple of other parameters.
The second table will have the following columns
- Profile Number (int)
- Segment Number (int)
- Time (int)
- Setpoint (int)
- and about a dozen other parameter columns to go with each setpoint segment.
I was going to query the first table by the profile number, which will return just one record. Querying the second table will return a variable number of records, one for each segment, which I will query ordered by segment number.
Is this a good DB design? Or is there a better way to build the schema, maybe a relational table or some other way?