I'm building a school project and my idea is to have a site where you can register an account, add a couple of users to that account and then calculate their monthly shared expense debt, e.g. User A pays 500 on groceries and user B only pays 250. This gives User B a debt of 125 to user A that month.
My problem is that I want to separate the accounts with the users. Now I have a setup of a table called Accounts with email and password and then I have a users table with particular user information. I want several people to be able to log in to the same account using different credentials.
Users table
ID, Name, Account_id etc.
Accounts table
ID, Email, Password, date_added, date_updated etc.
What is the best approach of doing this? Is it to have a cross-table called UsersForAccounts or do I specify several account_ids in the Users-table?
You wouldn't think of it as several users on one account. You would think of it as several user accounts that share a common group setting.
So you have a user's table as you may expect - each with its own values for that person, obviously.
Then you have a related table that shares the details for the group. Let's use a fraternity or something as an example.
SO you have Pi Phi as a group name. Within that are Users A, B and C.
A very very basic table structure might look like this:
Users: id, email, password, name, group_id
Group: id, name
So a user would - by this setup - have a relation to only one group. You could make that a relational table so a user can have many groups if you want.
The general idea here is that you use the group as a separate connection point to the user and not necessarily several users that access with the same account.
If that is unclear, feel free to ask and I may update
You can use a structure such as in the Users Table:
ID, Name, etc.
And in the Accounts table use simplest:
ID, Email, Password, date_added, date_updated, User_ID, etc
This is called Many to One relationship, and is ideal to your case.
A small tip i can pass to you is use LOWERCASE to ALL your fields, or in special to the first character of the name of the field, with an excerpt for "ID" (that is only a acronym (or similar) to Identification)
In an basic example, the Users table has the fields:
ID, name, etc.
And Accounts table the structure above:
ID, email, password, date_added, date_updated, user_id
This can't help much in a short time, but it can help you, and very much, at use of the database with PHP.
Related
I created Users table.
After the user registered, The system enter his address, phone, city and more personal details to Users table.
There is another table, called Contacts, there the user add another people details.
Now, if there is Contacts table, How better to save the personal details of the user in Users table? in one json column that contains all the user personal details, or in normal columns (address, phone, city)?
I just do not want to happen a situation of multiple data.
I think separate columns for each field will be the better option!
Well, it would of course be easy to just store it as JSON, but that way, it could be a bit messy to search for certain stuff in the database (say you wish to check all users from a given city for example).
When it comes to user information, I always find the best way to do this is to store only login vital data and the base info in a users table.
Something like:
id | email | password
And then have different tables for the other data.
Name and such (which a user only has one of (of course one could have multiple names, but I usually only store first and last names)) could be stored in a user_information table, which is in a one to one relation with the user (foreign key for the user_id so that it can be quickly fetched when needed).
When it comes to address and phone number, a user could actually have multiple.
I understand that its possible that your system/app is only supposed to support one address or one phone number and the like, but its always nice to make it "right" from the start, so that its easy to just let the user add multiple of them whenever the need is there.
That way, you would have a few different tables:
users
user_information
addresses
phone_numbers
and so on...
The user_information, addresses and phone_numbers would preferably all have a user_id column which would be used for a foreign key to point at the user who owns it. And if you wish to make it possible to use the same tables for contacts, a contact_id could be added too (and a foreign key to point to the contact).
I'm storing job profiles in my db kinda like Linkedin does.
you can sign up as a candidate or as a company but now i have only one table
user_tb
where user_tb.user_type is the tag to identify a candidate user vs a member/visitor, vs. a company
Imagine if i wanted the users to be able to add their own employees of that company.
where the employees should be stored? I'd store them in the main user_tb right?
so what about companies? and if i store employees in the same user_tb their email cannot be empty... how can i fill emails if i don't have them?
shoudl be user_tb a separate table from employees?
I would create a separate table for companies and users, and then have a column on the users table for their company id to link them together. It gets too messy when you try to cram everything together into one table.
If the users table requires an email, and you're wanting a place for companies to add employees, you can require them to give the employees email, or create a separate table for employees that doesn't require an email, but can be checked before signing up a new user to see if they already exist in the "employees" table.
I'm thinking about User and Person relationship in OOP and DB model.
Person is someone who use the application, for example a buyer for web-shop application.
To use the application, person has to be application User which can login and logout.
Let's say I have this:
Person (id, firstname, givenname, address, phone)
User (id, e-mail, username, password)
How to connect this two entities with association ?
Should User have person_id: User (id, e-mail, username, password, PERSON_ID)
Or should Person have user_id: Person (id, firstname, givenname, address, phone, USER_ID)
Please, tell me if I went completely wrong direction.
(I'll use PHP and laravel but that's not so important for this question).
It depends on the nature of your data.
Do you need to have users and persons being seperate entities? If you have some users who are not persons (eg. system user, cron user, etc.) then have Person contain a user ID. If that's not a concern for you (ie. all Users are Persons, period), I would create a single table containing all of the data, it's simpler.
I can't think of a case where I would want a User containing a Person ID.
I have developed a PHP and MySQL website which has a registration form for users and a payment for running races.
The problem is some people, want to pay without registration despite they have to type the runner info on every race payment.
My actual MySQL Schema is
USERS (id, username, password, email)
USER_PROFILES (user_id, name, surname, gender, birthdate, etc...)
EVENTS (id, name_desc, date)
REGISTRATIONS (id, user_id, event_id, signup_date, bank_order, bank_result)
At the beginning it was very easy to register some runner, store all the info, and go to EPOS, receive the order and result of bank, and I have an SQL to retrieve all registered runners who paid the event running race.
Now I am blocked in the idea, how to do if an user, doesn't want to register, or don't have an email account.
My idea is the possibility of developing an simple form to fill a form runner data, and go to pay, or type another, and then pay all ammount of all runners instead each one in their account.
Due to my website schema, I don't know how to improve my actual site with this other feature.
I hope I have explained everything perfect. Sorry about my bad English.
Thanks colleagues.
Ricardo. Yet Another PHP Developer.
You should consider adding the concept of a "guest user".
Basically, you treat "guest" checkouts the same as your regular checkouts, but you would add a new type column to your USERS table. Your new schema might look like this: USERS (id, type, username, password, email)
Choose an identifier for the type column like 'R' (for "Registered") and 'G' (for "Guest") and you'll be able to easily discern which kind of user you've got.
You'll have to update your site's code to disallow logins for guest users and not require those accounts to have a password or username, but all the other tables should be able to use the provided user_id of the guest user.
Also make sure your database schema doesn't have a Unique index on the Users.email column, as that'll prevent a user from going through the guest checkout multiple times.
I'm going to allow companies to register on my website and create job listings.
I'm currently approaching the problem by creating a Company table with Name, Logo and Password fields. Then when a person registers he can say, "I belong to X company"; at this point, I'll request the password written in by the initial registrator. If she/he enters the correct password then he is given permission to create job postings in the name of the company.
Why I'm doing things this way:
If I just put everything inside of the Company table, every new user would have to create an account and I'll have redundant information, CompanyName, Logo, etc.
And if I do things without a password, anyone can post a job opening under a companies name and that's just wrong.
Care to share some input? Am I doing things wrong? How would you do it?
I would do "jobs requests" like Facebook's friend requests and if the user really work in that company, the company manager just has to login and confirm it.
Database Normalization.
Create a separate Users and Companies table. Can one user post for multiple companies? if so, you need a many-to-many relationship (which requires a third table to keep track of the relationships). Otherwise, a one-to-many should work.
You should create two tables:
Company:
- id
- logo
( - name, etc )
User
- id
- companyId (foreign key to Company.id )
- password
( - username, etc. )
This way a User is a child of a Company identified by companyId. Now, if a user logs in, you can identify what company s/he belongs to by finding the Company corresponding with the companyId. Now you have a password per user, and a company per user.
And like Jimmy says, if you need Users to be able to be part of more Company's you would get:
Company
- id
- logo
User
- id
- password
Company_User
- companyId (foreign key to Company.id )
- userId (foreign key to User.id )
in my opinion you should create table like
Employers:
eid(pk)
logo
Username
Password
profile
etc....
JobSeekers:
jid(pk)
Username
Password
etc...
JobPosts:
id(pk)
eid(Fk to Employers.eid)
JobTitle
Specifications....