4

I have an application where a user is able to sign up by providing email, username and password.

This would be stored in mongoDB collection Users_Table. Now also the app allows users to sign with their social media account, if the user has one such facebook, google account and twitter.

Question is how do i go about designing the database?

My initial idea is to have 2 separate collections. The first collection has user information if he or she registers with the app. 

User_Table (
Id,
firstname,
lastname,
email,
phone_number)

The second collection stores the social media account such as facebook, google, or twitter if the user has one.

I will retrieve users firstname, lastname, email and phone_number from their social media account and store it in the collection. This will be stored in the second collection.

Now if a user who has signed in with facebook decides to register with the app, how do i merge both accounts i.e. if its the same user how do i link them?

Shrabanee
  • 2,706
  • 1
  • 18
  • 30
EI-01
  • 1,075
  • 3
  • 24
  • 42
  • Be aware that the phone number is not available via API (for Facebook), and that you only will get an e-mail address if the user has one on file with Facebook (which is not the case for a lot of people that registered using their mobile.) You should identify FB users via their app-scoped user id. – CBroe Jun 08 '16 at 08:11
  • @CBroe yes thanks i am aware of that. – EI-01 Jun 08 '16 at 16:23
  • @CBroe thanks for the response. Scenairo here: if user decides to log in with facebook credentials only, i can get basic info such as firstname, lastname and email. But linking that to the user collection won't that be a problem? Since user collection is meant for when user is registering with the application and that includes the password field which will be required – EI-01 Jun 08 '16 at 16:23
  • @CBroe or should the password field not be required. The reason i thought about having 2 collections was if the user decides to log in with social account it should be in one collection and if he decides to register with the app it should be in another collection. And i was thinking of embedding the user objectId in the social account collection. The approach obviously would be comparing emails since i'm assuming the user's email with social account would be the same with registering with the app. But if email is not the same then i cannot link or my assumption would be wrong. – EI-01 Jun 08 '16 at 16:23
  • @CBroe is my approach wrong? – EI-01 Jun 08 '16 at 16:24

2 Answers2

0

hmm, what was the business decision behind using mongo?

Why I'm asking? As someone decided to switch to mongo - it will be perfect to use advantages provided with it.

So my advice will be embed those details in one collection:

user:{
       /* base fields */
       _id, firstName, lastName, nickName, userName, email.... etc
      socialAccount:[
                 {
                    type:"facebook/twiter/whtsEver"
                    name, /*and all  other stuff you need here*/
                     }]
}

Then what app need is to make ONE call to mongo and get ALL data at once. No joins required.

profesor79
  • 9,213
  • 3
  • 31
  • 52
  • thanks for the response. Scenairo here: if user decides to log in with facebook credentials only, i can get basic info such as firstname, lastname and email. But linking that to the user collection won't that be a problem? Since user collection is meant for when user is registering with the application and that includes the password field which will be required. – EI-01 Jun 08 '16 at 16:18
  • or should the password field not be required. The reason i thought about having 2 collections was if the user decides to log in with social account it should be in one collection and if he decides to register with the app it should be in another collection. And i was thinking of embedding the user objectId in the social account collection. The approach obviously would be comparing emails since i'm assuming the user's email with social account would be the same with registering with the app. But if email is not the same then i cannot link or my assumption would be wrong. – EI-01 Jun 08 '16 at 16:22
  • @user3497437 when user register via facebook - then we will get facebook auth info, when decide to use userName/Password then we can add related data to document - for this case we can add field login/registration Type to determine that – profesor79 Jun 08 '16 at 16:26
  • password shouldn't be required in database model - all logic should be shifted to application, as on this level you will know how to give acces for particular user – profesor79 Jun 08 '16 at 16:28
  • so basically what u are saying is embed the social account into the user collection like the example provided above. And also what is name defined in the social account array – EI-01 Jun 09 '16 at 05:29
  • @user3497437 didn't get last question – profesor79 Jun 10 '16 at 10:28
0

Well, this is an old question but I will leave a hint just in case someone else gets the same doubts. I struggled with the same problem a long time ago and this article helped me a lot. But let’s summarize: First, you need a table to store all the user info (name, surname, email, phone...) then you need another table to store all the info related to Thirds Party sign in /sign up integration (provider_id, user_id, bla bla...). Then you need to figure it out a way to merge the accounts created via email + password with the ones created with other providers, for that we always think in comparing fields like email, phone or names but that’s not an option (because obviously people could use different emails for their social media, they could have hide their email like Apple allows, the name is not the same, etc.. there is thousands ways how this could go wrong), so basically this is NOT an option you don’t do that. So the better approach (not an actual solution unfortunately) to do this is to ask the user to link their accounts (in their profile for example logged with his/her username + password) you just ask the user to login to their social media account and then you just "connect" your two tables in your database because now your are "almost" sure is the correct user (this is what some video games does and then give regards to the users etc..) Notice this "connect" means that you need to check if that third party account previously registered to your system and then you link it and if it’s the first time then you just also link it and then the user can use it to access his account in your system the next time they login. There is also an automatic way to do this, you actually do the previus comparation (the one I mentioned before that you shouldn’t do it and compare some field and found some "potential matches of possible the same account or duplications") but then you ask the user if it’s really his/her account and ask him/her to login into that third party provider with his her credentials (same approach but now you are suggesting the matches) and then you do the same "connect" process. Well more or less that’s approach but it’s waaaay better explained in the article by Peter Nijssen (mate where ever you are thanks !)

Well I hope this help someone! Best regards!

Marlon Alejandro Espinosa Cast
  • 415
  • 3
  • 6