Database design question
-
I would go with 1 (ok solution) or 2 (better solution) Solution 3 was just dumb to the max.
With (1) you would have to hardcode any combobox (for example) containing the different possible entries. With (2) you wouldn't know which one is each.. Diff between 2 and 3 would be that in the program itself you would have to use: someMatch.Status.Finished == true vs someMatch.Status.Description == 'finished' But im not convinced, though, of solution (3)
-
With (1) you would have to hardcode any combobox (for example) containing the different possible entries. With (2) you wouldn't know which one is each.. Diff between 2 and 3 would be that in the program itself you would have to use: someMatch.Status.Finished == true vs someMatch.Status.Description == 'finished' But im not convinced, though, of solution (3)
-
I have a table of football matches, and each match can have 5 different statuses: Not started, 1st halftime, Break, 2nd halftime, Ended My question is, what is the correct way of modeling this?: Matches (MatchId, Status, ...) where Status is an integer or a string corresponding to each status vs Matches (MatchId, StatusId, ...) where StatusId is a foreign key to MatchStatuses, MatchStatuses (MatchStatusId, Description) vs Matches (MatchId, StatusId, ...) where StatusId is a foreign key to MatchStatuses, MatchStatuses (MatchStatusId, Description, IsNotStarted, IsFirstHT, IsBreak, IsSecondHT, IsEnded) for example, a registry in this case would be: (1, "First Half time", false, true, false, false, false) THANKS!
Depends on what questions you want to answer. If the only question you want to answer is 'What is the status of a match?' then first suggestion is good enough. This effectively means you have a one-one relation between matches and statuses. If you want to answer questions like 'What were half-time and full-time scores of a match?' then you have a one-many relation between matches and statuses so you need to use your second suggestion. Your third suggestion seems to offend first order normalization. I'd go for the second approach because it's more flexible. This may also mean moving some columns from Matches into the statuses table (e.g. the score since you have both half and full time scores).
Regards David R --------------------------------------------------------------- "Every program eventually becomes rococo, and then rubble." - Alan Perlis
-
Alivemau5 wrote:
With (2) you wouldn't know which one is each..
public enum MatchStatus
{
NotStarted = 1,
FirstHalf = 2,
HalfTimeBreak = 3
//.. etc
}If you have code relying on this, the enumerate it in code.
You have convinced me. And for users privileges do you think its a good idea to have the following?: Users (UserId, UserTypeId, ..) UserTypes (UserTypeId, Name, MayAddMatch, MayDelMatch, May..., May.., May... ) with registries like (1, "Admin", true, true, true...) (i'm not doing an offtopic.. its a similar question)
-
Depends on what questions you want to answer. If the only question you want to answer is 'What is the status of a match?' then first suggestion is good enough. This effectively means you have a one-one relation between matches and statuses. If you want to answer questions like 'What were half-time and full-time scores of a match?' then you have a one-many relation between matches and statuses so you need to use your second suggestion. Your third suggestion seems to offend first order normalization. I'd go for the second approach because it's more flexible. This may also mean moving some columns from Matches into the statuses table (e.g. the score since you have both half and full time scores).
Regards David R --------------------------------------------------------------- "Every program eventually becomes rococo, and then rubble." - Alan Perlis
Well my second suggestion was more like a table with 5 registries than a table with n registries, that is: (1, Not started) (2, First Half) (3, Break) (4, Second half) (5, Ended) And no more columns.. not this: (1, Not started) ... (23, Not started) I think you understood that This second suggestion was thinking on that I could fill any later combo (for example) without hardcoding it.. but the enum solution works and I wouldnt need to hardcode.
-
I have a table of football matches, and each match can have 5 different statuses: Not started, 1st halftime, Break, 2nd halftime, Ended My question is, what is the correct way of modeling this?: Matches (MatchId, Status, ...) where Status is an integer or a string corresponding to each status vs Matches (MatchId, StatusId, ...) where StatusId is a foreign key to MatchStatuses, MatchStatuses (MatchStatusId, Description) vs Matches (MatchId, StatusId, ...) where StatusId is a foreign key to MatchStatuses, MatchStatuses (MatchStatusId, Description, IsNotStarted, IsFirstHT, IsBreak, IsSecondHT, IsEnded) for example, a registry in this case would be: (1, "First Half time", false, true, false, false, false) THANKS!
Alivemau5 wrote:
My question is, what is the correct way of modeling this?
Normalization[^] would be the way to go, with most tables ending up in the third normal form. A joking reference during design would be "The Key, the whole Key, and nothing but the Key, so help me Codd[^]" :)
I are Troll :suss:
-
I have a table of football matches, and each match can have 5 different statuses: Not started, 1st halftime, Break, 2nd halftime, Ended My question is, what is the correct way of modeling this?: Matches (MatchId, Status, ...) where Status is an integer or a string corresponding to each status vs Matches (MatchId, StatusId, ...) where StatusId is a foreign key to MatchStatuses, MatchStatuses (MatchStatusId, Description) vs Matches (MatchId, StatusId, ...) where StatusId is a foreign key to MatchStatuses, MatchStatuses (MatchStatusId, Description, IsNotStarted, IsFirstHT, IsBreak, IsSecondHT, IsEnded) for example, a registry in this case would be: (1, "First Half time", false, true, false, false, false) THANKS!
I say 2 because that would be normalized. The enum would prevent hard coding but you really don't want to have to refer to app anytime you want to know what the value is... For instance if you are just looking at the data in the table not in the app. Also if you do it the second way rather then the enum you don't have to modify the enum every time you add a row.
Humble Programmer
-
With (1) you would have to hardcode any combobox (for example) containing the different possible entries. With (2) you wouldn't know which one is each.. Diff between 2 and 3 would be that in the program itself you would have to use: someMatch.Status.Finished == true vs someMatch.Status.Description == 'finished' But im not convinced, though, of solution (3)
Alivemau5 wrote:
With (2) you wouldn't know which one is each..
You could know which one is which this is how we do it. This may not be the cleanest way but it is very easy to maintain. We create an integer array such as
Dim blah() as Integerand set a default size for it close to what we think the number of records will be to minimize the use of redim. Then do something like this with the record set you retrieve.While myReader.Read
cmbControl.Items.Add(myReader.GetString(1))
lKeyIndex(lIndex) = myReader.GetValue(0)
'
lIndex += 1
' see if we need to redimension the array...
If lIndex Mod iCurrentDim = 0 Then
iCurrentDim = iCurrentDim + iDefaultDim
ReDim Preserve lKeyIndex(iCurrentDim)
End If
End WhileHere is a example query.
SELECT `UniqueNumber`, `Description` FROM `ct_contsources_master` WHERE `Inactive` = 0 ORDER BY `Description`
Notice the Inactive flag... If you use this than if a row is no longer valid you can set it to 1...therefore not populate the combo. EDIT.. Oh yeah this will help..
Public Function fiSetComboIndex(ByVal lKey As Long, ByRef cboControl As ComboBox, ByRef lKeyIndex() As Long) As Integer
' this routine sets the current "SelectedIndex" to the lKey passed in...
Dim iII As Integer
Dim iKeyIndexLength As Integer = lKeyIndex.Length - 1
'
fiSetComboIndex = 0
For iII = 0 To iKeyIndexLength
If lKeyIndex(iII) = 0 And iII > 0 Then
Exit For
End If
If lKeyIndex(iII) = lKey Then
fiSetComboIndex = iII
Exit For
End If
Next
End FunctionUse this to get the value that is selected.
blah(comboBoxName.SelectedIndex)
Store the result of that in the main table.
Humble Programmer
-
I have a table of football matches, and each match can have 5 different statuses: Not started, 1st halftime, Break, 2nd halftime, Ended My question is, what is the correct way of modeling this?: Matches (MatchId, Status, ...) where Status is an integer or a string corresponding to each status vs Matches (MatchId, StatusId, ...) where StatusId is a foreign key to MatchStatuses, MatchStatuses (MatchStatusId, Description) vs Matches (MatchId, StatusId, ...) where StatusId is a foreign key to MatchStatuses, MatchStatuses (MatchStatusId, Description, IsNotStarted, IsFirstHT, IsBreak, IsSecondHT, IsEnded) for example, a registry in this case would be: (1, "First Half time", false, true, false, false, false) THANKS!
-
-
No, and it would leave room for more in the future. And maybe you would use it as the base for other sports, like American football or baseball or who knows what. It's a proper pattern to use anyway, even if there are only two entries.