Alright, this isn't really Laravel specific, but let's think about it...
We'll most definitely need two tables, which we can call users
and invited_users
.
For our users table, you simply put whatever details you need, such as first name, last name, email, password, etc.
For our users_invited
*, the bare minimum is an inviteCode
and used [bool]
column, but a referrer
column is useful if you want to give something to the referrer.
*I chose this name because both users
and users_invited
will appear near each other in the database when managing your db
The best way to do this as I see it (there are of course different options) would be the following:
when a user sends an invitation to a certain email, we create a hash of this email and makes this the unique inviteCode
mentioned. This will then be appended to the link that is sent to the referred person. e.g http://example.com/?invite=6c132a79dbbc044c44952db50ed9e3b7. We then add the following data to our users_invited: inviteCode
, referrer
(optional, but needed for an award system), email
(also optional, but convenient to auto-fill registration field). Other than that, you can of course add whatever information you wish to generate date for users. E.g, you might wanna check how many invites a user has sent and how many of these were accepted to see the success rate, or store which people a certain user has invited (although this is easily done if you have both a referrer and email field in the users_invited
table.
We have two tables: users
and users_invited
.
The process will follow the following structure (excluding front-end part like response to referrer):
users_invited
table containing the inviteCode
and referrer
email address.inviteCode
.If our referral clicks the link we want to do the following:
used
column of the invited_users
row affected to 1 to ensure the code cannot be reused.The method presented is made for a system based on exclusive invites. E.g something that requires an invite to join. If you instead only wish to have a referrer/referral system where a referrer gets granted some perks by making more people join, I'd suggest you skip the entire users_invited
table and simply store the hash of a person when they register. Then use this hash in any invitation url generated. This means that the url will be the same for every invite sent by person x.
I think that was it. If you have any questions, just ask!
Cheers!
Thanks man! I have one more question. I have system like this: I send you invite and you accept that invite and fullfill registration form. Now You and me are roommates. Should i make one more table like roomates with id of user who sends invite and one who accept's that invite. Roommates table would look like this ID, user_who_send_invite_id, user_who_accpet_invite_id. Because i will need in the future the list of people who live together.
Cheers!
rasparac said:
Thanks man! I have one more question. I have system like this: I send you invite and you accept that invite and fullfill registration form. Now You and me are roommates. Should i make one more table like roomates with id of user who sends invite and one who accept's that invite. Roommates table would look like this ID, user_who_send_invite_id, user_who_accpet_invite_id. Because i will need in the future the list of people who live together.
Cheers!
That depends. Can a user live in multiple homes? If that's the case, there are a couple different ways to do it. However, if you only live in one place, the by far easiest way to do it is add a column "roommates" to the users table where you store an array of the people living together.
The second solution, which allows for both single and multiple homes, is to keep a separate table homes
, apartments
or similar. This table would then at the very least containay to do it is add a column "roommates" to the users table where you store an array of the people living together.mes, is to keep a separate table homes
, apartments
or similar. This table would then at the very least contain id
and inhabitants
. Then, you add the column homes
to users, and simply have an array of ids of the places where a user lives, or a single id if you can only have one place. The inhabitants
column of homes
would register who lives in the house. However, this column is pretty useless since you can just do a Users::where('home', '=', $houseId)->get()
or such. If you do still want to use the separate homes
table, that can be good since it allows for future development if you want to add specifications for different homes or whatever. You can also store the number of inhabitants if there is a max or similar.
Sign in to participate in this thread!
The Laravel portal for problem solving, knowledge sharing and community building.
The community