I have an issue that I could not figure out. I need to clarify that I am very new to phpmyadmin, mysql, databases and dreamweaver.
Currently, I have one table (book) which contains these attributes (ISBN(primary key), title, author, publisher, price etc) in phpmyadmin
I have the other table (users) which contains these attributes (username (primary key), password, name, DOB etc) in phpmyadmin too.
Let me explain the series of steps for my webpages first. An user logs in on the log in page successfully, and he will be directed to the main page, then he will type or select his search terms, then the results page will display the relevant results in the master list, then he will select the specific result to go to the detailed page containing more information.
What I want now is to create a reservation page. If the user likes the specific book, he can click reserve it, and will be directed to the reservation page.
I intend to have these search textfields: Username, Title, Price, and Number of books.
How can I let the username textfield to be automatically filled with the username as the user has logged in at the login page initially.? Also, how can I let the title and price textfield to be automatically filled with the relevant title and price, as the user has clicked reserve it at the specific detailed page? I intend that the user just key in number of orders and press submit button. My 3rd database (reservation) will capture the info of username, title, price, and number of orders. Do i use insert record or update record?
Do i create a relational table in phpmyadmin by linking it with the keys from tables (book and users)? Will this be a many to many relationship?
You can use sessionId to display username in the textbox...
use javascript to automatic fill up the title and price....
for the 3rd databse u should use insert record and create 3rd table too...
Related
I was doing a mini project on Cryptocurrency tracking. I have a Users table in Mysql to store the details of registered users in my webapp.
When user logs in, they can see a table of cryptocurrencies. They can add a specific cryptocurrency as favorite from that table by clicking a button.
Now, when they click that button I want to store the id of specific crypto in a table. Since one user can add more than one crypto as their favorite, I can't store the CryptoId in a single cell. So, my requirement is, I need seperate "Favorite" table for every user. Whenever a new User registers, I want to create a new "Favorite" table for that user. How can I achieve this?
Please give me any solution or advice on this, or any alternative Idea on how I can implement this requirement of mine.
What you need is a many-to-many relationship table:
Users:
user_id
username
...
Crypto_Currencies:
cc_id
cc_name
UserCCFaves:
user_id
cc_id
Each time a user adds a favorite, you put a record in UserCCFaves linking the user and the crypto currency
Many-to-many relationships examples
I have two tables in my database..one is candidates_details and another one is users..in the users table i have two types of users one is vendor and another one is user..they both have same user_id column...and i have that user_id column in my candidates_details table..
So what i want to do is when vendor post candidate_details by using form ..i want to store that user_id
(where user_type_id=1)
in candidates_details table automatically..
Can anyone help me..Thanks in advance..
Let me help you out by giving a pictorial example. Assume you have two tables users and candidate_details. In users you are keeping record of all the registered users along with their types. In Candidate Details you are keeping their profile data. You create another table where you keep user types Be it vendor, contractor, supplier etc.
Now when you create your form to post data in your admin panel or which ever interface you have. Just create a dropdown for user_types, get the type id and add the user. With the type id in your users table you can easily query which type of user that is.
Now for saving that user's profile information in candidate_details table you only have to provide user_id. So creating one more table will normalize your db schema and saves a lot of hustle in your query building.
I'm trying to make a chat with dialogue fuction as my learning project. Any user should be able to write messages to another user and recieve answers from that user, and no one else should have access to that dialogue.
In MySQL, I've created table user with id, login, password and privileges, table message with id, author (FK to user id), message text, time of post, and dialogue id (FK), and also table dialogue with id, FK to one user, FK to another user and additional columns with some parameters. I want to make my chat the way it let me have all messages from two given users to each other with just one query, but in the realization above I have to check two columns to find one user first, and then check all entries with that user to find his interlocutor. Only this query will return me a dialogue PK which could be used to get all messages. I think this realization is totally wrong, but I can't find the way to fix it. I've tried to attach dialogue id to table user, but this made my base even more complicated.
What should I do?
Here is my first schema: http://puu.sh/qdLMw/f9acde605c.png But I've make another table which will containt both interlocutor and dialogue id. When some user write a message to another, a query request line from this table where current user set as sender and his interlocutor set as target, and get a dialogue id from this line. If there is no such line, system will run another query which switch sender and target in their places. And if result is empty again, new dialogue will be created with two lines in interlocutors table linking two users to each other. http://puu.sh/qdORJ/2122558f64.png
It looks just slightly better for me, and if someone have an even better answer, please tell me.
I've been looking into the best way of storing an undetermined amount of information submitted by a user. A friend of mine suggested using nested tables, however these don't appear to be a thing in MySQL.
The application will allow users to store pieces of text information per day (each day is a blank slate so to speak)
What I have currently is
-Users
--ID
--email
--password
-Things
--UID (made from date and user ID)
--Thing1
--Thing2
This works fine. The UID is the users ID and the date combined (i.e 71420150404) as each day will be different but I'm open to changing this. The application checks to see if there are any entries for that UID and if there isn't, creates a new row.
The problem I have is I'd like the user to be able to select how many pieces of information they would like to add per day. So instead of the static 'Thing1, Thing2' the user could theoretically have this go up to 'Thing100', and I'm fairly sure adding these as columns isn't the best way to go about this.
I looked into if its possible to store an array in a cell and I'd access it like that through PHP but the research I came across all suggests I shouldn't do this. Creating a new table per user also seems very inefficient.
What is the best way to go about this?
I would create 2 tables:
entry table: id (auto increment), user id, timestamp - each time a user wants to store things a record is created and the id is retrieved using last_insert_id()
things table: id (auto increment), entry_id (foreign key to entry table), thing ( to store whatever the user wants to store)
If a user wants to store 10 things, then you create an entry record, then using its id you create 10 records within the things table. This way you are completely flexible on the number of things a user can store.
Assuming I want to have a web application that requires storing user information, images, etc as well as storing status updates or posts/comments would I want to separate tables?
For example if I have a "users" table that contains users information like passwords, emails, and typical social networking info like age, location etc. Would it be a good idea do create a second table("posts") that handles user content such as comments and/or post?
Table one: "users"
UserID
Username
Age
etc.
Table Two: "posts"
PostID
PostContent
PostAuthor
PostDate
etc
Is this a valid organization? Furthermore if I wanted to keep track of media should I do this in ANOTHER table?
Table Three: "media"
ID
Type
Uploader
etc.
Any help is much appreciated. I'm curious to see if I'm on the right track or just completely lost. I am mostly wondering if I should have many tables or if I should have larger less segregated tables.
Also of note thus far I planned on keeping information such as followers(or friends) in the 'users' table but I'm not sure that's a good idea in retrospect.
thanks in advance,
Generally speaking to design a database you create a table for each object you will be dealing with. In you example you have Users, Posts, Comments and Media. From that you can flesh out what it is you want to store for each object. Each item you want to store is a field in the table:
[Users]
ID
Username
PasswordHash
Age
Birthdate
Email
JoinDate
LastLogin
[Posts]
ID
UserID
Title
Content
CreateDate
PostedDate
[Comments]
ID
PostID
UserID
Content
[Media]
ID
Title
Description
FileURI
Taking a look above you can see a basic structure for holding the information for each object. By the field names you can even tell the relationships between the objects. That is a post has a UserID so the post was created by that user. the comments have a PostID and a UserID so you can see that a comment was written by a person for a specific post.
Once you have the general fields identified you can look at some other aspects of the design. For example right now the Email field under the Users table means that a user can have one (1) email address, no more. You can solve this one of two ways... add more email fields (EmailA, EmailB, EmailC) this generally works if you know there are specific types of emails you are dealing with, for example EmailWork or EmailHome. This doesn't work if you do not know how many emails in total there will be. To solve this you can pull the emails out into its own table:
[Users]
ID
Username
PasswordHash
Age
Birthdate
JoinDate
LastLogin
[Emails]
ID
UserID
Email
Now you can have any number of emails for a single user. You can do this for just about any database you are trying to design. Take it in small steps and break your bigger objects into smaller ones as needed.
Update
To deal with friends you should think about the relationship you are dealing with. There is one (1) person with many friends. In relation to the tables above its one User to many Users. This can be done with a special table that hold no information other than the relationship you are looking for.
[Friends]
[UserA]
[UserB]
So if the current user's ID is in A his friend's ID is in B and visa-verse. This sets up the friendship so that if you are my friend, then I am your friend. There is no way for me to be your friend without you being mine. If you want to setup the ability for one way friendships you can setup the table like this:
[Friends]
[UserID]
[FriendID]
So If we are both friends with each other there would have to be 2 records, one for my friendship to you and one for your freindship to me.
You need to use multiple tables.
The amount of tables depends on how complex you want your interactive site to be. Based on what you have posted you would need a table that would store information about the users, a table for comments, and more such as a table to store status types.
For example tbl_Users should store:
1. UserID
2. First Name
3. Last name
4. Email
5. Password (encrypted)
6. Address
7. City
8. State
9. Country
10. Date of Birth
11. UserStatus
12. Etc
This project sounds like it should be using a relational DB that will pull up records, such as comments, by relative userIDs.
This means that you will need a table that stores the following:
1. CommentID (primary key, int, auto-increment)
2. Comment (text)
3. UserID (foreign key, int)
The comment is attached to a user through a foreign key, which is essentially the userId from the tbl_Users table. You would need to combine these tables in an SQL statement with your script to query the information as a single piece of information. See example code
$sql_userWall = "SELECT tbl_Users.*, tbl_Comments.*, tbl_userStatus FROM tbl_Users
INNER JOIN tbl_Comments ON tbl_Users.userID = tbl_Comments.userID
INNER JOIN tbl_UserStatus ON tbl_Users.userID = tbl.UserStatus
WHERE tbl_Users.userID = $userID";
This statement essentially says get the information of the provided user from the users table and also get all the comments with that has the same userID attached to it, and get the userStatus from the table of user status'.
Therefore you would need a table called tbl_userStatus that held unique statusIDs (primary key, int, auto-incrementing) along with a text (varchar) of a determined length that may say for example "online" or "offline". When you started the write the info out from e record using php, asp or a similar language the table will automatically retrieve the information from tbl_userStatus for you just by using a simple line like
<?php echo $_REQUEST['userStatus']; ?>
No extra work necessary. Most of your project time will be spent developing the DB structure and writing SQL statements that correctly retrieve the info you want for each page.
There are many great YouTube video series that describe relational DBS and drawing entity relational diagrams. This is what you should look into for learning more on creating the tye of project you were describing.
One last note, if you wanted comments to be visible for all members of a group this would describe what is known as a many-to-many relationship which would require additional tables to allow for multiple users to 'own' a relationship to a single table. You could store a single groupID that referred to a table of groups.
tbl_groups
1. GroupID
2. GroupName
3. More group info, etc
And a table of users registered for the group
Tbl_groupMembers
1. membershipCountID (primary key, int, auto-increment)
2. GroupID (foriegn key, int)
3. UserID (foriegn key, int)
This allows users to registrar for a group and inner join them to group based comments. These relationships take a little more time to understand, the videos will help greatly.
I hope this helps, I'll come back and post some YouTube links later that I found helpful learning this stuff.