Gérer deux types de joueurs : avec et sans inscription

[Ter Rowan]

simple is not stupid

[Xenos]

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.

[niahoo]

simple is not stupid

Et justement pour le moment on peut dire que même si c'est conceptuellement simple, c'est plus du bricolage qu'une vraie solution simple et élégante.

@Xenos en effet sur un autre projet j'ai une table accounts et une table identities, qui permet à un même compte d'avoir plusieurs identités, dans le sens « identification ». Facebook, mail/password, twitter, etc. Je pourrais donc utiliser ce système pour gérer l'invité comme une nouvelle identité et créer le compte. Bon il va falloir que je le recode car je jette l'ancien code.

Je vais creuser cette voie.

Bon du coup ça se sera à faire quand j'implémenterai justement les autres moyens de login.