comment stocker/modéliser des utilisateurs/des utilisateurs facebook/des utilisateurs linkedin, etc, avec ActiveRecord ?

Question

Mon application a

• utilisateurs "normaux" : ceux qui passent par une page d'inscription typique
• utilisateurs de facebook(FB) : ceux qui proviennent de Facebook connect
• Utilisateurs "FB-normal" : un utilisateur qui peut se connecter à la fois avec son email/mot de passe * FB connect

En outre, il existe une multitude d'autres méthodes de connexion de type openID (je ne pense pas que l'openID lui-même soit acceptable puisqu'il ne relie pas les comptes et ne permet pas les fonctionnalités spécifiques aux tiers (publication sur Twitter, ajout d'un post FB, etc.))

Alors, comment je modélise ça ?

Actuellement, nous avons la classe User avec #facebook_user ? défini - mais cela devient compliqué avec les utilisateurs "normaux" de FB - et toutes les validations deviennent très délicates et difficiles à interpréter. De plus, il y a des méthodes comme #deliver_password_reset ! qui n'ont aucun sens dans le contexte des utilisateurs de Facebook uniquement. (c'est nul)

J'ai pensé à STI (User::Facebook, User::Normal, User::FBNormal, etc.) Cela rend les validations super astucieux, mais il ne s'adapte pas aux autres types de connexion, ni à toutes les permutations entre eux... User::FacebookLinkedInNormal(wtf ?) Faire ça avec un tas de modules, je pense que ça craindrait beaucoup.

D'autres idées ?

Answer 1

Vous êtes en train de courir dans un de ces inadéquation de l'impédance objet-relationnel les mines terrestres.

Facebook et LinkedIn résolvent ce problème en utilisant des magasins clés/valeurs non relationnels. Facebook utilise Cassandra et LinkedIn utilise Projet Voldemort .

Lorsque vous n'êtes pas lié par les conventions du modèle relationnel (par exemple, toutes les lignes d'une table donnée ont les mêmes colonnes), vous pouvez gagner en flexibilité et varier les attributs par ligne. Mais ce faisant, vous sacrifiez certaines forces du modèle relationnel (par exemple, toutes les lignes d'une table donnée ont les mêmes colonnes).

Dans un SGBDR, j'architecturerais ceci en utilisant Héritage des tables de classes .

Answer 2

Je diviserais les préoccupations, il semble que cela n'ait pas de sens de garder des enregistrements qui ont des champs très différents dans une seule table.

Il suffit d'avoir un modèle/tableau Utilisateur qui n'enregistre pas d'informations d'identification, et de faire en sorte qu'il ait une relation has_many avec une méthode Compte/Login, où vous pourriez utiliser STI pour modéliser les différents types.

class User < AR::B
  has_many :accounts
end

class Account < AR::B;end

class PasswordAccount < Account;end 

class GoogleAccount < Account;end

class FacebookAccount < Account;end

…