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.
Related
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 want to create 3 tables: boss and employe inheriting the table person.
person: id, login, password;
boss: id, login, mdp, firstname, lastname, email;
employe: id, login, mdp, firstname, lastname, email;
I separate those two types of persons for control the rights.
But I want to keep a table that contains all users to manage a connection.
The problem is the auto indentation in the three Ids. When I create a member of type "boss", the ids in the tables boss and "person" are auto identated at 1. And when I create a new member of type employe, The ids (1 in "employe" and 2 in "personn" beacause the first is the boss) are not the same.
How I can modelize it?
Thanks and sorry for my English, Florian.
You have a lot of duplicate data being stored. Consider this alternative:
person
------
id
login
password
firstname
lastname
email
boss
----
id
person_id
employee
--------
id
person_id
I can store the exact same information using this structure as you can in yours, but each 'person' will only have a single firstname/lastname, email address, login and password. You should only store in the boss / employee tables information that is relevant to only that entity. A boss for instance might have a security_code field whereas a regular employee wouldn't.
You shouldn't try to keep id primary keys between two different tables to match up (i.e., boss id doesn't need to match person id). Instead, add the person_id foreign key so that if you have a boss record you can easily lookup their information in the person table from that.
i have three tables to store details of different types of uses: customers, suppliers, staff
here are the structures of them,
customer(id,f_name,....)
supplier(id, name, address....)
employee(id, name, job_title....)
now i need those to log-in to the system , the log-in details stored in separate table,
user(user_id, password, role, ref_id)
how i planed to work this is, when registering some one, firstly insert the record to customer, supplier or employee according to the person, then insert a record in to the USER table in which the "ref_id" is the id of the previous table. the user is provided the "user_id" which can not be changed and they can change their password themselves.
when log-in, check the user_id, password combination, if ok then takes the ref_id and type, the appropriate table can be determined by the type which may be customer, supplier or employee....
the reason i done this in above way is,
customer, supplier and employee table has many different attributes except few like id, name...so can not maintain all the data in one table. in this situation if we use ids of customer, supplier and employee..would provide duplicate ids because they are separate tables!
so i need to know,
Is it correct the way i have implemented the authentication ?
if it isn't what is the correct way? (please mentioned that the details of the three parties should be handled separately)
i need to define relationship between supplier, customer, employee --> with user table. so is it ok to define three relationship as follows or another solution, how if the user table keep alone without relationship? is it violate the relational database concept?
customer (id-pk) ---->user (ref_id-fk)
supplier (id-pk) ---->user (ref_id-fk)
employee (id-pk) ---->user (ref_id-fk)
The problem I have is this: I have in my requirements a Users table and a Roles table separated.
users(id, login, password, id_role, name, last name, telephone, ...)
roles(id, role, description)
I already have read and followed the authentication example here but it has the role in the same table as the user's data. I don't know how can I relate both tables in cakePHP, especially in a login module. Can someone please help me?
You should read the CakePHP cookbook. The next topic after the simple authentication and authorization chapter is how to build an ACL-controlled application, which is what you’re after: http://book.cakephp.org/2.0/en/tutorials-and-examples/simple-acl-controlled-application/simple-acl-controlled-application.html
http://book.cakephp.org/2.0/en/tutorials-and-examples/blog-auth-example/auth.html
Change field roles to role_id and add relation Role hasMany User (User belongsTo Role)
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.