Question

my website enables two ways to login (similar to many websites including stackoverflow).

1. register your email and password and login afterward.
2. Login with Facebook connect

so I got a User class (I’m using Ebean [JPA]).
when a user logged in with facebook connect I extract basic information using facebook Graph API.

now, should I differentiate (in the DB level) between the two types of users? (for example, creating separate table for FacebookUser. I heard also about table inheriting. is it feet my situation?)

what is the best practice for this two types of login options?
I should mention that I’d like in the near future using Google account as a way to login.

Answer 1

I suggest you use a users table that contains basic information about your users, regardless of registration mechanics (below it’s a barebones example):

id | name | email | date_created

Different services will have different auth methods, so maybe it’s a good idea to have different tables for each:

auth_facebook:

id | facebook_id | access_token | …

auth_website:

id | password | …

And so on. Usually, the ability to login using multiple services is there for convenience, you probably would want to centralize your users one way or another. It’s also good to keep in mind that with regards to authentication, you’ll have your primary id in the users table, but you’ll have different validation methods depending on the service the user uses to connect. For Facebook, you can check against the facebook_id after auth and see which of your users logged in. The schema above would allow you to offer users to connect other services too, which can be helpful.

A specific case would be if you have basic profiles for people, but you want to allow them to show off their GitHub repos, SO rep and allow them to connect with Facebook friends at the same time.

Table inheritance sounds like overkill and most likely different implementation in different database systems. A view of all these tables could be more suitable.