I can post the SQL schema and conversion queries, as soon as I have them close to complete, based on decisions here. I mostly wanted to get people's quick impressions on the feasibility of using mapping tables, and it seems (so far...) that it's not a completely out-to-lunch idea.
As Peter noted, the yes/no enums will be replaced by simple bools. And there may be a couple of places where pre-configured arrays of strings are a better option than mapping tables. I'll go through the current schema and see what I can come up with. Most of the code so far has been related to security (see my other email), which is not affected in any significant way by the database schema, or else auto-generated and slighly tweaked. Definitely no hog-wild coding going on here yet. :-) Greg. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dave O'Neill Sent: Thursday, January 07, 2010 2:44 PM To: Development discussion for the Leaguerunner league management system Subject: Re: [Leaguerunner] Converting Leaguerunner to CakePHP On Thu, Jan 07, 2010 at 01:59:35PM -0500, Greg Schmidt wrote: > I've gotten started on this, though still quite a ways from having a URL or > code to share. It probably makes more sense to agree on a new database schema and a way to migrate existing data before we go hog-wild on coding anything. Can you post your SQL to the list? > One thing that's come up is the issue of enums in the > database schema. We currently use these in a number of places (province, > player class, even yes/no values), but they are not part of ANSI-standard > SQL, and are not supported by (at least) MS-SQL (not sure about the latest > version). As such, they are also not well supported by the auto-generated > code that CakePHP builds. I see three options for proceeding. Yeah, the enums need to go. There are equivalent features in other databases, but they don't all work the same. > 3. Change the enum columns to ints referencing new tables (e.g. there would > be tables called provinces, player_classes, etc.). This keeps the database > small, but adds a bunch of new tables. On the other hand, some of these > tables now become things that can be easily edited through the app, if > appropriate. The auto-generated code would (I believe, I need to verify > this) handle this option without changes. I think I'd prefer this option. 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
