I've been racking my brain over this for a few days now, and being fairly new to 'back end' stuff, I haven't managed to come up with a table structure that works. What I'm trying to do is create a wish list feature which allows users to save a course to their profile for later. Originally, I created three fields in my 'users' table, named: 'saved_course1', 'saved_course2' and 'saved_course3'. I then tried to come up with a php/sql code that when a user clicks the wish list button on a courses page, the id of the course is saved to the one of the saved courses fields (providing that it isn't already filled), however someone pointed out to me that this would be an terrible way of doing this and it would mean my db wouldn't be normalised.
So to sum my problem up, I need help with creating a table structure that would allow users to save multiple course id's to their account, then allow me to get the id's of the courses and display them in a table on their profile page. Sorry if this makes no sense, as I'm finding it difficult to put it into words.
That's not so difficult just make this table structure below. Let me know if you don't understand it
Example
User(userid,name,etc)
Courses(coursesid,name,fee, etc)
WhishList(userid,coursesid)
userid is foreign key to User, null not allowed
coursesid is foreign key to Courses, null not allowed
Extract courses for particular user
select * from WhishList join courses on Whishlist.coursesid = Courses.coursesid where WhishList.userid = "USER_ID HERE";
Related
So I have two different tables, a users table and an articles table. The idea is to allow a user to rate an article, but only allow them to rate it once (possible change their existing rating too but I can come to that conclusion later).
As of now I just have the update value working to allow them to rate the article, but of course a user can rate an article as many times as they want.
To give you an idea of how I have everything working, when a user logins in, a session is created with their user information. So when they go to rate an article, I have the ability to check the user, I just don't know how to stop them from rating if they have already rated a specific article.
The user table consists of among other things their username and their unique ID
and the article table consists among other things the article contents, the article unique ID, and the articles rating.
I had some really sloppy ideas like when the user rates an article their ID gets stored into the articles row in some kind of "users who have rated" column, and then I can do a for loop or something to siphon out all the user IDs and then check if their ID exists in that articles entry but then each article would have a row with possibly hundreds or thousands of userIDs on it and there seems like there would be a more elegant way.
Any help or direction is appreciated :)
Create a UserRatings table which has foreign keys to the users table and the articles table, and stores a row linking the user to the article, and the rating they gave it and when it occurred.
Then if a user tried to rate it again you just check this table for the user ID/article ID combination before allowing it.
And then if you wanted got can do things like show the user a list of articles they have previously rated, etc
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'm new on programming, sorry if I can't explain my doubt very well...
My friend have a online game and I help him to manage it. The php has a table for the users (meh_users), and a table for the items that the users have (meh_users_items). Each item has a id, (column itemid) and also the users (column userid), and in the table of the items that the users have, there is a id for the combination of the user and the item. (just id, and sorry, I don't understand this so much).
There is an image, if this make more easy to understand me:
phpMyAdmin printscreen
I want to add an item (let's think that it's a sword and this item have the id 3454) to all the users, but I don't want to delete the other items that the users have. Also I don't want to insert the data on the table one by one, because it's more than a hundred users.
Hope I have said enough details!
Remember: I'm new and I already search soooo much in the internet before asking here.
I suppose you want to give that sword to all users, including ones that already have it. You don't need PHP for this, SQL is enought.
INSERT INTO meh_users_items (userid, itemid, equipped)
SELECT userid, 3454, 0
FROM meh_users
This is just an example. You need to add all field to SQL.
Three steps:
If it isn't there already, add the new item (e.g., the Sword of Power) to your meh_items table.
Get a list of all your users from the meh_user table.
Write a foreach statement creating an entry in the meh_users_items table for each user.
It also occurs to me that your database might have some setup issues. E.g., meh_users_items has a column indicating item type (e.g., weapon). That could end up being problematic. Better to keep that information with the items in the meh_items table.
I am new and trying to make a simple website for a project. I have to pages, add and view hobbies. User needs to be able to add 1 or more hobbies and store it in a database and to retrieve it in another page, i have listed what i plan to do below.
How do i make it such that I am able to store multiple hobbies for users in the database?
Using MySQL, HTML, PHP, Dreamweaver
Assume: User has been created, user has been logged in and all user related database coding has been done. More than 1 user exists, all users are to have a few hobbies each.
Database
User table: UserId, Username, HobbyId
Hobby table: HobbyId, HobbyName, HobbyDaysAWeek
1 user can have 0 or more Hobbies.
Add hobby page
dropdownlist (binds list of hobbies from hobby table)
textbox (for user to enter how many days a week he spends engaging in that hobby)
add button (displays value in dropdownlist and textbox in a table)
table (Hobby and daysAWeek will be shown here, with a delete icon to delete it)
submit button(saves hobby & days a week & username into database)
View hobby page
Displays user's hobby & days a week in a table.
Thanks for helping! And please provide simple and bare minimum coding as i am new!
Well, nobody posted an answer but my question was answered in the comments so..
Start by adding a 3rd table with UserId and HobbyId – Dagon
You're storing the relationship between, not a relationship. So think of it like you have two things and you want to remember that they relate. Thus, a table with two columns, one with an identifier of one part, the other with identifier (ID) of the other part. Pull them together with the data about each part, you have information. Hence, you've stored the relationship. It's like metadata, really. It's usually pretty efficient. - Jared Farrish
Thanks guys!
I am currently working on a system that would allow users to add additional custom fields for the contacts that they add.
I wondered what is the best and most efficient approach to add such ability?
Right now what I was thinking was to have 1 table per users (with foreign keys to a "main" contacts table) and then adding a column for each custom fields that the user adds (since I don't expect to have more then 100-200 users per database shards [sharding is easy since every users never see each-other's content in this system]), although I am not 100% sure that this would be the right solution for such problems.
Maybe you could try to have one separated table to store a reference to the user, plus the field name and value, this way you will be able to have lots of custom fields.
If you go with Boyce-Codd, you separate the information and store them into a table.
Means one table for all users with a foreign key.
One table per user would lead to hundreds or more tables with possible repeated information.
You need to have one table named USERS that stores the id of a user and fixed info you might want. Then, you could have a CONTACT table, that stores the type of contact user might create, and one matching table USER_CONTACT that matches the user unique id with the id of the contact that was created.
With this, you could have advanced data mining on all the information stored, like nowing how many contacts each user created, who created more, etc...