zidance's avatar

How should I design if I have to store multiple social platform profile?

I am doing a system which need to allow user to connect multiple social account and store the related info for them.

I have a database design in my mind which looks like this. I will have a users table to store info like username, password. Then user_profiles table to store main info like name, image, age, etc. Then a pivot table to link them to multiple social platform user_profile_platform to store user_profile_id, platform_id, platform_type. Then I have the last table platforms to store info like followers, biography, etc which related to the social platform inform.

Appreciated if any feedback on this to improve on my current design structure. Thanks!

0 likes
6 replies
lbecket's avatar

I think you need to ask yourself what the relationship is between these various entities. user_profiles, for example, appears to be a 1-to-1 with the users table and so it would seem redundant in this case. A user can only have one name, age, etc. and so I would store these attributes on the users table directly. Incidentally, age changes and so I would store birth date instead and calculate an age accordingly.

I also wouldn't store things like followers on the platforms table since a platform will have many followers. Instead, store data that is unique to a platform instance on your platforms table and link things like users through a platforms_users table.

In the case of relating users to platforms, these three tables: users, platforms, and platforms_users are all that is needed to track those associations. In other words, your users and platforms have a many-to-many relationship and the platforms_users table serves as the pivot to form that relationship.

From this point, any additional related attributes to users or platforms can be stored in their own respective tables and, depending on their relationships, linked back directly or through other pivot tables.

zidance's avatar

@lbecket What I am trying to do is to store multiple platform details, because I am allowing them connect with multiple social account, where they can switch to perform some actions in my apps. So, my users might consist another type of user, I decided to split it into a table for example user_social_profiles to consolidate all the main info into this table and link to the platforms table. This platforms table is to store all unique data belong to themselves, e.g. total count of followers.

The use case e.g.

I login as User A, I allowed them to connect with their social account e.g. Facebook, instagram, YouTube etc. When they connected, I will store the related data into my database for application usage.

This is just basically what I am going to do.

lbecket's avatar

@zidance It just occurred to me that your platform users may have many profiles based on having many social platform accounts. In that case, I think you are on the right track with a user_profiles table where one user for your system has many records in the user_profiles table. From there, each user_profiles record is effectively equivalent to the user that I described above as being in the users table and all of the same principles apply.

Again, just ask yourself how the various entities are related and the answer should dictate the table structure.

martinbean's avatar

@zidance Most “connect your account” or “login with X” services are based on OAuth, so when the user approves the connection you’ll get an OAuth access token to act as that user. So you can merely have an access_tokens table with a foreign key pointing to the owning user. You’ll also need to store the service name, and you could also optionally store the service’s unique identifier for the user in this table.

So I usually have an access_tokens table that looks something similar to this:

$table->id();
$table->foreignId('user_id')->constraint();
$table->string('provider'); // Twitter, Facebook, etc
$table->string('provider_id')->nullable(); // Users ID on external service
$table->string('access_token');
$table->string('access_token_secret')->nullable(); // For services using OAuth 1.x, i.e. Twitter
$table->unique(['user_id', 'provider_id']);

The unique constraint ensures a user can’t connect to the same service more than once.

zidance's avatar

@martinbean Alright, thanks! I did something similar, but because of user profile stored in my database doesn't necessary need an OAuth method to authorise the connection at first place. It's more like shadow user until they are onboarding to us. And also my user might had different info for profile storing. So, I am using polymorphism on users to differentiate the type. After that the profiles table will link to a table store all the provider info like you mentioned here to do the stuff.

Please or to participate in this conversation.