Instead of a table within the main database of this webapp !! simply because, a SRA or a league wants control and rights ...a league will want more admin features over their own information .. more than clubs do ! ...
In short ... this is a webapp for Canada, somekind of a Full Soccer Sports social network with a full featured & embeded soccer management online tool ( destined to where ever they call the game Soccer instead of football .. like North America ( Canada in occurrence) .. starting with Quebec, the province I live in ) ... just within the island of Montreal alone, In Quebec, there are more than 300 teams within one Soccer Regional Association ! ... ( there are 15+ SRAs in Quebec ) .. a league as I am referring to it, is in fact a soccer regional association looking over and managing many different leagues ( A, AA, AAA, schools and local leagues, etc ) in its own territory, and overseeing the clubs and soccer activities in that same territory ! .. so the league ( the SRA) wants more control ! ... to accommodate that ... I want provide them with the option of creating their own database within the app and oversee with their own information in it, manage their subjects ( like registration for players, teams, clubs, etc.. manage competitions, series, calendars .. etc .. ) .. ! ... but .. then again ... it is a lot easier for me to keep it all under the same database ! .. with just a whole bunch of tables .... but I may end up with lots of tables with redundant information ... Imagine for a moment that I end up with all Soccer Regional Associations in Canada ( heck ! - what about the US ) signing up .. having it all in one single database could become my biggest concern ... As for their need to control and to have many rights ... that can be done within their own tables in the webapp application ... Yes .. it is a lot easier ! but I have to have the other option available as well .. .. !! anyways ... thank you for the thoughts ... Meanwhile I still have problems with the wizard forms .. it is not working the way I want ... Depending on the usertype chosen, the rest of the subscription form is a bit different ... so far .. I am exploring the possibility to have everyone sign up ( straight up and simple ) .. and only when they get to their incomplete profile page ... .. only then .. they will be reminded to fully complete the remaining forms based on their usertype and then provide them with their proper page settings and layout ! ( Yes .. each user type has different settings ) .. the user page of a club will be different then a player's page ! .. ( they will look just a little bit the same ! but they will not be the same, will not have the same menus and choices ! and so on .. ) 2012/6/20 Cliff Kachinske <[email protected]> > Why do you say this: A league will most definitely needs its own database > instead of a table ? > > I ask because it's probably not true. > > On Wednesday, June 20, 2012 10:12:13 AM UTC-4, Don_X wrote: >> >> A league will most definitely needs its own database instead of a table >> ... while a team can have its own table within that league database !!! ... >> but can a database be created on the fly within the app upon registration ?? >> >> On Wednesday, 20 June 2012 10:02:27 UTC-4, Don_X wrote: >>> >>> Hello, >>> >>> In the model, in the file db.py I used the auth_user table that comes >>> by default with web2py and I enriched it a bit the following way : >>> ##############################**########## >>> db.define_table('auth_user', >>> Field('first_name', type='string', >>> label=T('First Name')), >>> Field('last_name', type='string', >>> label=T('Last Name')), >>> Field('email', type='string', >>> label=T('E-mail')), >>> Field('password', type='password', >>> readable=False, >>> label=T('Password')), >>> Field('sex',requires=IS_IN_SET**((T('male'),T('female'))),labe**l=T('My >>> Sex is')), >>> Field('usertype',requires=IS_**IN_SET((T('player'),T('coach')**,T( >>> 'referee'),T('Parent, Soccer Fan or Volunteer'),T('League, Club, School >>> or Team owner'),T('OTHER (ex: Health,Sponsor,etc)'))), >>> label=T('I am a')), >>> Field('birth_date','date',labe**l=T('Birth Date')), >>> Field('created_on','datetime',**default=request.now, >>> label=T('Created On'),writable=False,readable=F**alse), >>> Field('modified_on','datetime'**,default=request.now, >>> label=T('Modified On'),writable=False,readable=F**alse, >>> update=request.now), >>> Field('registration_key',defau**lt='', >>> writable=False,readable=False)**, >>> Field('reset_password_key',def**ault='', >>> writable=False,readable=False)**, >>> migrate=settings.migrate) >>> >>> >>> I am using mysql on my local server, it all works ! the problem or issue >>> I am having is this : >>> In the usertype field, I have 6 predefined user types ... >>> 1) I wanted to user numbers ( like 1, 2, ... 6) internally to shorten >>> the various codes I'll be writting when it comes to compare or to decide on >>> the actions of that specific usertype ! >>> (PS. I am thinking that it is somekind of a list so I can refer >>> to that field as auth_user.usertype[0 to 5] to identify the specific >>> usertype of a subscriber !!! ... am I on the right track ??? ) >>> >>> 2) *** THIS IS MY MOST IMPORTANT QUESTION *** >>> Depending on that user type, the associated profile and form to fill out >>> that follow will not be the same upon registration !! ... in other words, >>> depending on the usertype chosen by the user, as I am using the form wizard >>> recipe, >>> the next steps ( and certain fields ) to be shown will not be the same >>> ... so .. I definitely need to create separate table for each user type >>> ???? ... what if a specific user type ( such as a club and a league) >>> actually needs its own database instead of a table in my main database ! >>> ??? how do I approach this in the model and consequently in the controller >>> to the view ??? >>> To put it in context : a player or ref or coach is a user, ( simple ) >>> ... and most club owners and persons will be the same basic auth_user ! but >>> on the other hand ... >>> a team is a list of registered users >>> a club is a list of teams and users ( that >>> are not teams ) >>> a league is a list of clubs and users ( >>> that are not clubs, like volunteers, workers, etc.. ) >>> >>> Am i approaching this the right way ??? ... >>> >>> please advise >>> >>> thank you >> >> -- William James nous dit : '' La plus grande découverte de ma génération est que l'être humain peut transformer sa vie simplement en modifiant sa maniére de penser.'' -------------- Le Don X --
