Je vous suggère d'utiliser un users qui contient des informations de base sur vos utilisateurs, quelle que soit la mécanique d'enregistrement (ci-dessous, c'est un exemple de base) :
id | nom | email | date_créé
Des services différents auront des méthodes d'authentification différentes, donc peut-être est-ce une bonne idée d'avoir des tables différentes pour chacun :
auth_facebook :
id | facebook_id | access_token | ...
auth_website :
id | mot de passe | ...
Et ainsi de suite. En général, la possibilité de se connecter à l'aide de plusieurs services est là pour des raisons de commodité, vous voudrez probablement centraliser vos utilisateurs d'une manière ou d'une autre. Il est également bon de garder à l'esprit qu'en ce qui concerne l'authentification, vous aurez votre identifiant primaire dans la table users, mais vous aurez différentes méthodes de validation en fonction du service que l'utilisateur utilise pour se connecter. Pour Facebook, vous pouvez vérifier le facebook_id après l'authentification et voir lesquels de vos utilisateurs se sont connectés. Le schéma ci-dessus vous permettrait de proposer aux utilisateurs de se connecter à d'autres services également, ce qui peut être utile.
Par exemple, si vous avez des profils de base pour les gens, mais que vous voulez leur permettre de montrer leurs dépôts GitHub, SO rep et leur permettre de se connecter avec leurs amis Facebook en même temps.
L'héritage des tables semble excessif et il est fort probable qu'il soit implémenté différemment dans les différents systèmes de bases de données. Une vue de toutes ces tables pourrait être plus appropriée.
