KCBS Team and Member Tracking
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 |
I think I would like to address each of your points
Quote:
Quote:
Quote:
Quote:
Quote:
|
You are absolutely correct. We implemented the KCBS membership database. I have been pushing KCBS to use an ID # to identify a team for years now but they insist on using the spelling of the team name. This policy has been carried over to the new scoring program. We are writing the software to import data from the new scoring program into the database and we have to rely on the way a team's name is spelled to identify the team. Obviously we will encounter a lot of exceptions where the team name was spelled incorrectly and the software has to be able to deal with that, along with providing a user interface so the office staff can resolve discrepancies and correct errors in the imported data. This is all unnecessary work and expense.
Garry |
In database terms the team would be the primary key and the members of the team would be the secondary key. Your primary key must be unique. A primary may have any number of associated secondary keys.
In programming terms it is a very simple concept. From what I have heard through the board discussions they are in for one heck of a cluster fark! |
Quote:
I don't know that it matters what that field in the input is called as long as the output is there and it's a number that you are able to match with a name later. Is that correct based on what you are planning to do? Edit: I've discussed the software with Garry in the past month or two, but did not realize that the current software would not but using a unique # to identify teams. My understanding was that a number would be used and that it was under discussion. Having talked to Garry, I've got confidence in his development philosophy and experience to deliver the best product possible to KCBS. |
Quote:
They mentioned adding a spot on the spreadsheet for the head cooks number. That should help with the match but a primary key ID number for the team would work much better. As an example of how this could get screwed up, I was going through scores today while eating lunch. I saw the following two team names "Bu-Ba-Q" and "BubaQ". Is that the same team? What happens if BubaQ gets Bu-Ba-Q's scores because if the download finds a match it won't produce an error. Like I said above, I see a cluster fark in the making unless they make these fixes soon and it sounds like they are running out of time quickly. |
Quote:
dmp |
Quote:
My point was just reiterating others above that if you only use team name for the download you will have problems every single week at pretty much every single comp. |
Quote:
|
Quote:
dmp |
Quote:
|
I just don't follow KCBS's insistence that teams are identified by exact spelling and not a number! This is totally ridiculous! Assign every team a number and member numbers that go on that team. Allow a member to be on more than one team or say UP TO three teams (for example). People say "well what about those teams whose members are not KCBS members? Simple... either program it so non-KCBS teams are just not given a number and thus, as would be the case anyway, they don't get points or assign all non-KCBS teams some higher number, possibly starting with 9 or whatever, and they STILL don't get points.
By not assigning team numbers, the Board is creating same ol' same ol' problems for the organization in the end and they will have wasted their efforts in designing new scoring software. We (KCBS) have a FANTASTIC opportunity to do something really good here and it's gonna be blown if it proceeds as it has been reported to be going here. One final point that Divemaster made was spot ON - this should all have been hammered out in committees and taken to the board for approval or rejection and if rejected, suggestions given to the committee to go back to the drawing board! Come on guys! MICROmanaging again! |
Because of the ‘Unique’ spelling of our team name I’ve had to contact KCBS at least a number of times in the last year. A primary key of a unique number is the only way to go…..
Jeff Stockcar BBQ Aka… Stock Car BBQ Stock Care BBQ Stock Yard BBQ StockCar B.B.Q. Stock Car B.B.Q. Stockcar B-B-Q Stock Car B-B-Q |
Am i the only team that has reps double check our name? Even reps that know me double check my name and spelling on the official list. As they are doing their Friday walk around, prior to cooks meeting they always come up to make sure they have it right...
|
Quote:
|
They double check mine as well several times the have Rub One Out instead of Rub Won Out. They must be perverted or something:icon_blush:
|
Quote:
Quote:
|
I modestly build financial databases for work and once it's setup it's easy to maintain and run queries and analyses from. I don't see why they wouldn't go this route. Excel would even easily used to build one.
|
Yep. I think everyone is in agreement that from a technical standpoint, the challenge is minor. At this point it seems to be some sort of political, stubbornness, or misinformation issue. If that's really the case you have to wonder how many other seemingly simple issues are in the same boat...
|
Folks,
I'm sorry for acting like a smarty pants the other day. My point in doing that was to demonstrate that I really, really know what I'm taking about here. Next to my family, I probably devote the most attention in my life equally between systems design and BBQ. This is not just something I chose to spout off on, it's what I live every day, when not thinking about my next competition:) Anyway, my real point here is that I agree with what others have said and then some. I mean no offense to any of them, but no one on The Board of Directors of the KCBS should be making database design decisions unless you have a university degree in that field or 5+ years experience doing it. I wouldn't expect the BOD to tell a health department what is and isn't safe, and I don't expect them to tell software designers what is and isn't a good database design. What I mean is that it really doesn't matter one bit whether you call it TOY or COY. It doesn't matter whether you want the internal ID of a team entity to be visible outside of the database or not. Sound database design says that a team is an entity here, and the BOD should let some one else, tell them that. Please consider what I wrote in the OP of this thread as an hour's worth of free consulting on how to design a database, and if you don't agree with it, ask five other professionals (at least three others have sounded off in this thread). I honestly can't think of a single organization where its board of directors makes database design decisions. That is left to employees or consultants who know what they are doing. Why isn't that happening here? Enough rambling though. As was mentioned, it appears to be universally agreed by those who should know that the current plan of a database is not the best way to do it. I started this thread in the Board section hoping that some one on the board would read it and take it to heart, but since no one has commented, I guess that isn't going to happen. Rather than sitting on our thumbs and saying what should happen, how can this be taken to the BOD for hopeful action? Should it be eMailed, or should we start an online petition, or maybe should some one who is a professional on the matter speak to the board at the 12/14 meeting? This is important, and I'd rather not just get a bunch of ppl to agree and then do nothing. Thoughts? dmp |
Quote:
|
Quote:
Quote:
My point is that all of this should have been hashed out / argued in a committee made up of people who understand / do this type of work. Said committee could then offer the BoD one to three choices with all of the pro's & con's for each listed and a recommendation as to which would be the best for what we need. At least then we'd have some expert opinions from folks who know what they're talking about. |
This thread made me smile, especially seeing "tuple" tossed out. I never thought I'd see the day when BBQ morphed into mathematica obscura but here we are!
Bottom line is when everybody tells you the same thing over and over you need to start paying attention. Regardless of how the rules regarding teams are handled, serializing teams is a technical commandment. Listen up BoD and have the job done right from the beginning or we are doomed to yet another painful reinvention a short time down the road. |
Quote:
Edit: I wanted to make sure that there is absolutely clear that no sarcasm is intended. It was clear, to the point, and should serve as a reminder that there is a reason subject matter experts are hired. |
Quote:
It is really amazing to see all the actual IT professionals who have tried to help KCBS fix this problem over the years. Even more amazing that every single one of them basically said the same thing. Of course the topper is that to a man every single one of them was ignored by KCBS. Really remarkable that you could get this many database folks to agree on a solution and still have it ignored. At least KCBS sticks to their guns? |
Quote:
There is a lot of semi technical discussion here about how to address the issues. This seems like a futile effort without clear requirements from the 'business' side of the organization. I'm not sure how IT professionals could help KCBS if there is not clear agreed upon system requirements. While we agree its a bad idea when the business side tries to make technical decisions. Its also a bad idea when the tech side tries to implement systems without good requirements or even worse tries to drive the requirements. |
Quote:
I've tried here to not push any business rules on the KCBS nor its BOD. My goal is not to tell them that they should have TOY vs COY nor any other business requirement. Still, I think that the technical requirements speak for themselves and demand best practices however the KCBS BOD wishes to proceed from a business rule perspective. A well designed system will fulfill those needs in a way which facilitates performance, scalabillity, reduction in errors, and flexibillity down the line should opinions and rules change. I would like the BOD to dictate what their requirements are, and while a DBMS consultant may ask questions and make suggestions, the business rules will ultimately be the decision of the BOD, hopefully with the opinions of the membership taken into account. Still, the nuts and bolts, the logical and physical ERM, would be the responsibillity of those with the training, knowledge, and experience to provide them in the best way possible. dmp |
Quote:
Quote:
Listening to the special meeting that covered the subject....I don't think enough people clearly understood the issue to make a reasonable decision. I don't think enough people had a grasp of what the wanted to accomplish. I think it was clear that there was not a consensus on how to proceed. A large part of the argument was about what # to use, how many cooks, etc... For software purposes the sole decision that needed to be made was how many characters the field would accept. Database management, based on my understanding is a different contract. Personally I'd hope that export would be in SQL or another common format as well as the option for import in the same format but that would have to be defined and the current timeline probably precludes that based on issues above. |
Quote:
Scenario 1 (Off line, non-realtime):
Using this approach, IDs are utilized, spelling errors are cut down and caught on the front end, and transmission to KCBS is simple. Scenario 2 (On line, semi-realtime):
dmp |
Chris was wise when he said the tech doesn't matter until the people agree on what they want to do.
After a couple decades in IT I've come to think of myself more as a common sense advisor than a technical guru. Tech is easy - people are hard. |
You programmers are making my head hurt! LOL!
|
Isnt Don Harwell on IT guy. And if heviant, hevunderstands what nweds to be goong on. Im not sure why Mike Budai is heading the committee now. But he just didnt seem to have an understanding of the innerworkings. If I am wrong I apologize, just my observations.
|
The whole thing reminds me of this Dilbert cartoon:
http://dilbert.com/strips/comic/2006-01-29/ |
I have requested to speak about this issue at the 12/14 board meeting. Let's see how that goes.
dmp |
Good luck - I hope that you get your allotted time without interruptions.
|
Well, They gave me my time to speak and it was uninterrupted. As far as I know it was recorded, but it appeared to be before the actual meeting began. Anyway, they all heard it, and then I got the distinct impression that no one really gave a damn. There was an interesting statement related to it after executive session, but I'll have to wait until the audio gets posted to quote it.
dmp |
Quote:
|
Quote:
dmp |
All times are GMT -5. The time now is 01:12 AM. |
Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
2003 -2012 © BBQ-Brethren Inc. All rights reserved. All Content and Flaming Pig Logo are registered and protected under U.S and International Copyright and Trademarks. Content Within this Website Is Property of BBQ Brethren Inc. Reproduction or alteration is strictly prohibited.