I am relatively new to to database relationships, and I would love some advice on setting up my database for a basic registration for sessions.
GOAL:
Post a new session that people can sign up for. Maximum of 8 people per session. Admin side can see those who have signed up.
Here is what I currently have from a front end (the signup box at the bottom is just there temporarily as I work with this):
I have the backend working to create a new training session on POST:
<?php
session_start();
include ('global/db/connection.php');
$session_name = $_POST['session_name'];
$session_description = $_POST['session_description'];
$session_date = $_POST['session_date'];
$result=MYSQL_QUERY("INSERT INTO trainingsessions (id,session_name,session_description,session_date,session_open_slots,session_booked_slots)".
"VALUES ('NULL', '$session_name', '$session_description', '$session_date', '8', '0')");
header("location: admin.php");
?>
I also have been able to query the table and display the results in the table above. What I am trying to figure out is what sort of relationship and tables I need to create between the users and then displaying the appropriate amount of slots that are still open.
Very basic, nothing fancy at the moment. Just trying to get some fundamentals in with not luck thru other searches. Hope this makes sense, and thanks for your help!
You will have a many to many relationship between users and sessions (presumably). In essence each user could be assigned to many sessions, and each session will have multiple users. For that reason, you need an intersecting table that creates a composite key (the primary key is defined by multiple fields). For example, I would make the following tables:
Table: user
Columns: ID (primary key), Username, email
Table: sessions
columns: ID (primary Key), Name, Description, Date
Table: user_sessions
columns: user_id, session_id
Using this structure, users can have multiple sessions and sessions can have multiple users.
Related
I've posted a few questions on here and have gotten very great help and support. I'm still fairly new to programming and I'm putting together what I thought would be a simple website for the company I work at. I apologize in advance for my lengthy post/question, I just want to be thorough and clear in what I'm asking. My question is more of needing some help getting pointed in the right direction of how to get started and some best practices to be aware of. What I'm working on right now is to create a system where a user can submit a questionnaire/online form to inquire about a specific product (in this case it's a hard money loan product). The way I am planning on setting it up is to have a database with multiple tables (users, user_info, loan_app, property) and connect these together by referencing each other. I've read about table joins and I understand them conceptually but I have no idea how to implement in practice. I've had a hard time finding actual examples.
Specifically, this is what I am doing and how I am thinking it should work (correct me if I'm wrong or if there's a better way to do it):
1- the user (aka the borrower) signs in to the website. The user log in system references the user table where things like first name, last name, user name, password and user ID are stored. I have included an "active" column in this table so that when a user logs in the condition for them to get into the website is that the username and password match AND the user is activated. This way we can control on the back end certain user accounts access. I have this part working.
2- when the user registers, they only fill out the information that creates a new record in the "user" table. I have created a second table called "user_info" that will contain other data like home address, phone number email etc. But I need to be able to associate the correct record with right user. This is my first issue to wrap my head around. My thinking behind doing this instead of simply putting all this information in the user table is that for one, I might keep adding to that table and make it very big, and two for security reasons, I would like to keep the information separate. I don't know if this thought process has any merit to it though. Again, that's why I'm posting this here.
3- The user, once logged in, clicks on a button on their home screen/dashboard that will take them to the loan "pre-approval application" form, which is the questionnaire. On this form their basic information will be echoed/posted from the "user_info" table to pre-populate certain fields like first name, last name, email, phone number, address etc. So going back to #2 making sure I can associate the user with the correct record in the "user_info" table is critical. THEN, there are additional fields that the user has to fill out in order to submit the application/questionnaire. These form fields will create a new record in the "loan_app" table. This table will have a loanid column that is the primary key for that table, and an auto generated/randomized 6 or 7 digit loan number (loannum). The loanid will be a hidden value but the loan number will be like a reference number that is associated with the loan for the life of it and used for later accounting and recording purposes internally, whether or not it actually becomes a loan. The loanid, I'm assuming here, is the Foreign key in the "user" table and the userid is the Foreign key in the "loan_app" and "user_info" tables correct? If so, how do I incorporate being able to simultaneously associate all these records when the loan application/questionnaire is submitted? My thought would be write individual php scripts that does each of these things separately then have a "master" php that includes all of those individual ones that is placed as the form action associated with the submit button on the form.
Thanks for taking the time to read through this. I'd really appreciate any advice or reference material that I can read up on to learn more about this stuff. My job has a pretty crazy schedule and I travel a lot so I don't have the time to take actual classes to learn this stuff formally. I'm pretty much doing this as I go.
Also, I'm using MAMP with mysql, not sure if that helps any or not...
The user table's primary key userid can be the primary key of the user_info table as well, since each user will have only one user_info record, right? A foreign key constraint is good to ensure only valid userids get recorded in user_info.
The loan_app table can contain a denormalized relationship from loanid to userid so that each loan application is associated with a user. Again, use an FK constraint for integrity.
Don't include loanid in the user table - that would mean each user has a relationship to a single loan application. You already have the one-to-many relationship you need in the loan_app table.
I want to design a DB which will be connected to PHP Application. In the app there are two types of users: company and person. Some functionality like adding articles will be done by both so in other tables there are author_id columns. So firstly I decided to create user column.
That's easy: id, username, password, role, active, created where role defines whether user is person or company.
Now I want to add profile table or profile tables depends on what you'd suggest (joined with the previous table by adding profile_id column there).
Both roles have different fields, which are required during registration.
The easiest thing would be to create one table with all required fields for both roles, allow them NULL values and in the PHP app (made in Yii Framework in this case) define requirements for each role in models.
The nicest thing would be to create separate tables for both roles BUT the questions is how to connect these two tables to one table using Foreign Key? Is it even possible. I know I may omit foreign key creation then based on role choose table, and from that table choose profile_id.
Or maybe you have another solution to my problem.
Thanks in advance for replies.
Adrian
You need an intermediary between the page and the database to assign the user to a group that has specific privileges. It's usually accomplished with a user-group-role design.
You can have a table for users system info (username , pass ...), and another for users profile (firstname , birthday ...), and another for groups(superuser , ...).
where user table can have multiple groups: user:one->group:many
user can have one profile user:one->profile:one
I think this is a decent solution.
I'm building a web application in work and I have a form where users can register certain types of information.
Username | Password | Company
Now I'm unsure how to approach this. What I want is when the user submits that registration form Username, password and company get written to one data table(user) BUT because Company, in the user data table, is a foreign key reference I need Company to be written to a separate datatable(company) as a Primary Key (and of course username to be written as a FK reference as its a 1 - 1 relationship).
I'm not looking for a coded solution from you guys because I know my PHP and MYSQL I'm just looking for some pseudo code algorithms to get the creative juices flowing!
EDIT: I AM USING POSTGRESQL not MYSQL but I'm pretty sure there's little difference except port numbers and small syntax changes
assume first column is id:
Save Company $mysqli->query("INSERT INTO company VALUES (NULL, '$company_name')";
Get id of this item. $company_id = $mysqli->insert_id;
Save User with this id $mysqli->query("INSERT INTO user VALUES (NULL, '$username', '$password', '$company_id')";
Get user's id $user_id = $mysqli->insert_id;
Update the company with it: $mysqli->query("UPDATE company SET user_id = $user_id WHERE company_id = $company_id)";
Begin to insert your compagny in your table compagny.
Get back the id. (There is a sql requete like LastInsertId)
Insert the user/password/IdCompagny in your table user.
EDIT : some help : http://dev.mysql.com/doc/refman/5.0/en/getting-unique-id.html
Some questions:
why is User:Company == 1:1? If I and a coworker join your site, do we need to pretend to work at different places?
if companies can have more than one employee, what kind of validation will you employ to combine variations on company names (e.g. IBM vs International Business Machines)?
what if a user is unemployed?
If Company is a nice-to-know datum rather than a required-or-things-break datum, I'd probably sign up my user first. Then, when the user logs in you can nag them for additional information. This has the added advantage of making user registration less onerous for the user.
A use case:
user submits username and password
filtre input for bad stuff and validate for duplication, suitability
save to db and retrieve user PK
load 'additional info' page and set a session var as a "nag" flag
-if user chooses not to fill out add'l info, nag flag can trigger reminder behaviour
add autocomplete to Company field so that user can use existing Company table entries
process form and save to db
either add company and associate user
or just associate user
unset session nag flag so your website won't continue to nag
My web app is going to have two types of users that are 100% different - in fields, functions, and purpose on the site. The purpose of one type of user is to post blogs, and the purpose of the other is to read them and "follow" the posters.
The ONLY stuff they have in common are the need for an id, email, password and a couple other bits of meta data such as date joined, etc.
Should I attempt to stem them from the same account table, or make one table for each?
NOTES
-One potential thing to think about is that, to prevent user confusion, I think emails between the two types of accounts should be unique.
-Readers and Authors will have different sets of data that will need to be stored about them aside from the normal "account" meta data.
I would separate them.
TABLE User {
id
email
password
salt
created
modified
}
TABLE follower {
user_id
...
}
TABLE author {
user_id
...
}
Over time your application will grow. Perhaps now you have two destinct roles - but it may change in the future. You may have authors that also follow other authors, or followers that are "upgraded" to authors. You might also start adding other "roles" and want something like this:
TABLE user_role {
user_id
role_id
}
TABLE role {
id
name
}
Define "user". If a user is somebody who has registered him or herself on your site, using an e-mail address, password and nickname, and who can log on, then stick everyone in the users table.
The things users can or can not do on a site does not differ for a user. It's their permissions that are different. Map permissions to users in a separate table. Don't create a table for each type of user.
Otherwise, when you're adding a new kind of permission in the future, you don't have to add a new table for that type of user (and alter all (sql) code that handles with users: logging in, resetting passwords, and so on). You just add a new type of permission, and map that to their respective users.
it will save you allot of work to just have one table and have a single column in the table that defines which type they are .
No, make one table for each. It will be easier to manage, it'll be scalable
I have some small issue with relationships with tables as below:
I have created a login and registration script which has the following
table name: members:
fields: member_id, firstname, lastname, login, password
Now i have made another table with this
table name: phone
fields: member_id, phoneid, name, number, prefix, time,total
I want to make a form whereby a admin can select the name of the client from a drop down list, and then add a record such as the number called, number prefix, total time and the amount for that period.
I dont know how to do this, please help me by creating a script or help me how to go about this.
So all the time a admin makes a form on Client A it gets added to a new row on the phone table, then i will just add a call script on the client side where they can see all the records that they have done.
Thanks please assist.
Regards
Your db design seems fundamentally flawed - the is no association between the members and the phone_numbers tables. Add a FK (member_id) to phone_numbers table.
Regards creating the front-end, there are quite a lot of libraries that have data stores (we use ExtJS), and upon flushing the store you can do the persistence with php.
Hope this helps!