My understanding of the day field would be to do two things: 1) Serve as part of the description of a league - Thursday Rec, Mon/Wed Competetive, etc. 2) During gameslot creation, only allow new gameslots to be assigned to leagues which operate on the days of the new gameslots.
Assuming there's no other uses to the 'day' field, my opinion on this would be: for use #1 - this can be accomplished just as easily as a string, or included in the league name field. for use #2 - I put forward that this isn't really required. It seems to be a sanity check to ensure the user doesn't make a mistake and schedule something on the wrong day by accident. I'm not a big fan of this. It's confused my league admins before that they needed to first set the 'day' field by editing the league before creating gameslots and making them available to that league. If the 'day' field or equivilant is deemed as being necessary, then the options appear to be (none of which I'm a big fan of): a) add a table with league_id and day fields (one-to-many), one row per sechudle-eligible day per league. I would say this choice gives database integrity while increasing program complexity b) boolean fields for each day - simplistic but not very rhobust or nice-looking database schema or code. On Thu, Jan 7, 2010 at 5:56 PM, Greg Schmidt <[email protected]> wrote: > Found another wrinkle in database conversion. The "day" column of the > leagues table uses the "set" feature of MySQL to allow leagues to be set up > to run on multiple days. Not sure how to handle this one. Seven separate > bools seems like overkill, as well as being clumsy to handle. I guess this > is used in scheduling, which I don't know well. Suggestions? > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Dave O'Neill > Sent: Thursday, January 07, 2010 2:59 PM > To: Development discussion for the Leaguerunner league management system > Subject: Re: [Leaguerunner] Converting Leaguerunner to CakePHP > > On Thu, Jan 07, 2010 at 02:35:54PM -0500, Peter McAlpine wrote: > > - I don't think a "Yes" "No" table is necessary (booleans are likely more > > appropriate here). > > Yes, we should definitely convert any yes/no enums to boolean. > > > - What impact do province have on the system? If it's just address > > information I'd say strings are ok. Are there really places that behave > > differently if a player is from one province or another? Perhaps would > using > > strings for this make LR a bit more location-portable (i.e. outside > Canada)? > > Good point. I'd like to see country and province in separate tables, so > that it's easier to constrain user input to valid choices, but the more > I think about it, it's probably not appropriate to reference into an > external table. Having a 'player' table with a bunch of numeric > foreign-key values that require you to join on several other tables just > to pull mailing addresses seems like a bit of a waste. > > A good compromise would be to keep address information stored as > strings, but use 'province' and 'country' tables to present the pulldown > choices in the edit form. > > As for behaving differently, OCUA frequently needs to take province > information into account for various reports, but we haven't needed > different runtime behaviour based on province. > > > - Player types may be something that's appropriate for a separate table. > > It would also give us somewhere to hang in-database permissions > management in the future. > > Cheers, > Dave > _______________________________________________ > Leaguerunner mailing list > [email protected] > http://www.dmo.ca/cgi-bin/mailman/listinfo/leaguerunner > > _______________________________________________ > Leaguerunner mailing list > [email protected] > http://www.dmo.ca/cgi-bin/mailman/listinfo/leaguerunner >
_______________________________________________ Leaguerunner mailing list [email protected] http://www.dmo.ca/cgi-bin/mailman/listinfo/leaguerunner
