J'étais fatigué tôt hier >.>
Dans ce cas, l'alternative que j'avais choisie consiste à stocker chez le client (le joueur non inscrit) les informations de son compte, et à ne les monter au serveur (en BDD) qu'une fois l'inscription "réelle" effectuée (donc, pour le serveur, c'est considéré comme un Visiteur finalement).
S'il y a besoin des interactions serveur, je serai alors parti sur une table intermédiaire qui représente un compte utilisateur, et qui se compose de trois colonnes: IdCompte [NOTNULL], qui stocke le numéro du compte utilisateur, UserType ['Inscrit', 'Guest',...] qui indique quel est le type d'inscription de l'utilisateur, et IdUtilisateur [NOT NULL] pour stocker l'id de l'utilisateur.
Si l'utilisateur est inscrit, on fait le lien avec la table des joueurs inscrits: UserType='Inscrit' ⇒ `IdUtilisateur`=`UtilisateursInscrits`.`Id`
Si l'utilisateur n'est pas inscrit, on fait le lien avec un cookie de session unique par exemple: UserType='Guest-Cookie' ⇒ `IdUtilisateur`=document.cookie...
Et cela facilitera le boulot par la suite: si l'utilisateur passe par OpenID: UserType='OpenID' ⇒ `IdUtilisateur`=OpenIDValue
Donc en pratique, cela revient à utiliser une table Guest, qui finalement permet de "typer" les comptes des joueurs et permettra ainsi de changer leur structure et leur nature facilement pour la suite.
Ouep, ça fait des bouts de code en plus dans la partie site web/contrôleur, mais si ce sont des objets construits par des Factories, il y a moyen d'ajouter les différentes classes requises (GuestAccount, OpenIdAccount,...) et d'instancier la bonne sur la base du type de compte.
Si t'as prévu de passer par OpenID et autres systèmes tiers, il me semble que tu auras besoin d'une structure souple à la fois dans la BDD et dans le code du site.
Dans ce cas, l'alternative que j'avais choisie consiste à stocker chez le client (le joueur non inscrit) les informations de son compte, et à ne les monter au serveur (en BDD) qu'une fois l'inscription "réelle" effectuée (donc, pour le serveur, c'est considéré comme un Visiteur finalement).
S'il y a besoin des interactions serveur, je serai alors parti sur une table intermédiaire qui représente un compte utilisateur, et qui se compose de trois colonnes: IdCompte [NOTNULL], qui stocke le numéro du compte utilisateur, UserType ['Inscrit', 'Guest',...] qui indique quel est le type d'inscription de l'utilisateur, et IdUtilisateur [NOT NULL] pour stocker l'id de l'utilisateur.
Si l'utilisateur est inscrit, on fait le lien avec la table des joueurs inscrits: UserType='Inscrit' ⇒ `IdUtilisateur`=`UtilisateursInscrits`.`Id`
Si l'utilisateur n'est pas inscrit, on fait le lien avec un cookie de session unique par exemple: UserType='Guest-Cookie' ⇒ `IdUtilisateur`=document.cookie...
Et cela facilitera le boulot par la suite: si l'utilisateur passe par OpenID: UserType='OpenID' ⇒ `IdUtilisateur`=OpenIDValue
Donc en pratique, cela revient à utiliser une table Guest, qui finalement permet de "typer" les comptes des joueurs et permettra ainsi de changer leur structure et leur nature facilement pour la suite.
Ouep, ça fait des bouts de code en plus dans la partie site web/contrôleur, mais si ce sont des objets construits par des Factories, il y a moyen d'ajouter les différentes classes requises (GuestAccount, OpenIdAccount,...) et d'instancier la bonne sur la base du type de compte.
Si t'as prévu de passer par OpenID et autres systèmes tiers, il me semble que tu auras besoin d'une structure souple à la fois dans la BDD et dans le code du site.