dmprantz
is Blowin Smoke!
I'm listening to the November special board meeting, and I have some thoughts, comments, and solicitation for input in regards to the team name and number.
One of the issues I have is to look at this from a technical point of view: In a database, each entity should have an ID. This ID uniquely identifies the entity throughout the entity's domain. From a logical, technical point of view, I see no reason why teams should not have their own entity with their own number. If some one came to me and asked me to design a system for teams competing against each other I would think it a an ER failure for me to not create an entity for the team. I know I'm not the only database and software guy who competes, nor the only on this forum, so does any one disagree with that? If teams aren't their own entities, then you are really only tracking individuals. Once you have entities (with IDs) for teams, you can setup the appropriate relations and track things accordingly.
Next, I'd like to take a step back and examine how this would work from a rules point of view. How will The KCBS accommodate teams with multiple people, some or all of whom may not be at every event. For this, I look at college and professional sports teams. Does any single person make a team? Are there not usually at least two quarterbacks? Isn't there an assistant coach who can take over if the head coach is sick? These are teams, and there is no "I" in that word. Non-team sports like golf don't have teams. One potential exception I can think of is doubles tennis, but that really is a special case because it is one time team made up of two individuals. What I would suggest from both a database and league standpoint is that a team has a roster of its members. The roster can be limited at some arbitrary number. It's 53 in the NFL, so say somewhere between 1 and 53. One prevents it from being a team, and 2, or maybe even 3 limits some teams. For a team to be officially present, at least one person from that roster (or maybe 51%?) need to be there. Implement something similar to a trade system and a trade deadline to allow new members and to allow people to change teams. That way you are keeping track of who is on a team and who isn't and are able to determine if a team is present. Print a list of all team memberships before the competition.
Another question or issue I see with this, is to ask are members allowed to be on multiple teams simultaneously? Obviously that's not possible in most sports leagues, but I can think of a few examples in competitive BBQ where it happens. I don't want to get into the pros and cons of it right now, but the KCBS should define a rule around that and stick to it. The database can (and should) be designed to support a many-to-many association right there in case rules change.
The final thought from me on this is to bring up that this doesn't affect every team. In general KCBS doesn't require membership to compete, and an individual's team name or affiliation can change with every competition. There are a few exceptions: TOY, Sam's Club Tournament, AR, and I think The Jack are all currently based on head cook, though some of them also have rules about who can be on your team in future events. While obviously the KCBS shouldn't impose its rules on other organizations, it could try to communicate any new team dynamics to them. KCBS should also figure out how the inconsistent team names fit into the paradigm. They can ignore them if they choose, but they should try to think about any consequences of that ignorance and be prepared to handle it. If TOY and Sam's Club are the only conflicts, they may be okay as they seem to have those covered.
Those are my thoughts as a professional software and database designer with multiple degrees and several years of experience to back them up. Some parts of it may seem complicated or require some extra work, but none of it should be extreme. Life is complicated some times, and to adequately resolve complicated issues, you sometimes need complicated solutions. The alternatives are to either not do anything, which is where the discussions come from now, or to do something half-baked and not be able to accommodate everything.
Thank you for your time in reading this,
Daniel
One of the issues I have is to look at this from a technical point of view: In a database, each entity should have an ID. This ID uniquely identifies the entity throughout the entity's domain. From a logical, technical point of view, I see no reason why teams should not have their own entity with their own number. If some one came to me and asked me to design a system for teams competing against each other I would think it a an ER failure for me to not create an entity for the team. I know I'm not the only database and software guy who competes, nor the only on this forum, so does any one disagree with that? If teams aren't their own entities, then you are really only tracking individuals. Once you have entities (with IDs) for teams, you can setup the appropriate relations and track things accordingly.
Next, I'd like to take a step back and examine how this would work from a rules point of view. How will The KCBS accommodate teams with multiple people, some or all of whom may not be at every event. For this, I look at college and professional sports teams. Does any single person make a team? Are there not usually at least two quarterbacks? Isn't there an assistant coach who can take over if the head coach is sick? These are teams, and there is no "I" in that word. Non-team sports like golf don't have teams. One potential exception I can think of is doubles tennis, but that really is a special case because it is one time team made up of two individuals. What I would suggest from both a database and league standpoint is that a team has a roster of its members. The roster can be limited at some arbitrary number. It's 53 in the NFL, so say somewhere between 1 and 53. One prevents it from being a team, and 2, or maybe even 3 limits some teams. For a team to be officially present, at least one person from that roster (or maybe 51%?) need to be there. Implement something similar to a trade system and a trade deadline to allow new members and to allow people to change teams. That way you are keeping track of who is on a team and who isn't and are able to determine if a team is present. Print a list of all team memberships before the competition.
Another question or issue I see with this, is to ask are members allowed to be on multiple teams simultaneously? Obviously that's not possible in most sports leagues, but I can think of a few examples in competitive BBQ where it happens. I don't want to get into the pros and cons of it right now, but the KCBS should define a rule around that and stick to it. The database can (and should) be designed to support a many-to-many association right there in case rules change.
The final thought from me on this is to bring up that this doesn't affect every team. In general KCBS doesn't require membership to compete, and an individual's team name or affiliation can change with every competition. There are a few exceptions: TOY, Sam's Club Tournament, AR, and I think The Jack are all currently based on head cook, though some of them also have rules about who can be on your team in future events. While obviously the KCBS shouldn't impose its rules on other organizations, it could try to communicate any new team dynamics to them. KCBS should also figure out how the inconsistent team names fit into the paradigm. They can ignore them if they choose, but they should try to think about any consequences of that ignorance and be prepared to handle it. If TOY and Sam's Club are the only conflicts, they may be okay as they seem to have those covered.
Those are my thoughts as a professional software and database designer with multiple degrees and several years of experience to back them up. Some parts of it may seem complicated or require some extra work, but none of it should be extreme. Life is complicated some times, and to adequately resolve complicated issues, you sometimes need complicated solutions. The alternatives are to either not do anything, which is where the discussions come from now, or to do something half-baked and not be able to accommodate everything.
Thank you for your time in reading this,
Daniel