I have a scenario where upon a person registering a new community I want them to automatically become a member of that community.
I have 3 tables:
users
id | user_email | user_password | user_name
communities
id | name | code | admin
community_playes
community_id | player_id
Upon the community being created I immediately need to run the following MySQL queries so that person becomes a member of said community:
1) To get community_id from table communities where admin = email and put into table community_players, community_id
2) To get id from table users where user_email = email and put into table community_players, player_id
I already have email as a variable.
My aim is to populate the community_players table with a new record containing the id of the user, and the community_id of the newly created community.
What would be the SQL statement for this? I have no experience in SQL.
Related
Information:
I have 2 tables(users for the users of the website and new_themes for themes/posts(whatever) created by the users.
!!!There is no relationship between these 2 tables.(A user can create a new post if he is logged in)
Tables:
Users:
1 id
2 name
3 email
4 password
New_themes:
1 id
2 title
3 text
4 upVotes
5 downVotes
6 TagName
What I want to do:
I created the feature that user can like the post(but he can like it unlimited number of times) but I want them to be able to like just once in a life time a post.
What I can't figure out is the idea/structure/logic of how to make it. I am thinking of creating a table . A "pivot" one for tables users and new_themes(many to many relationship in Laravel)
1 id_user
2 id_theme
Where the both of them have a composite primary key so they won't be any duplicate values, so if the user wants to vote once again the same post he won't because there can't be duplicate values.
Here is the problem:
If this is the solution, I have doubt and no idea on how to populate the pivot table when a user likes a theme. If this isn't the solution any advice or idea will be very helpful for me to finish my last feature of my wep app.
Thank you very much.
What I can't figure out is the idea/structure/logic of how to make it. I am thinking of creating a table . A "pivot" one for tables users and new_themes(many to many relationship in Laravel)
That's the way to go. So it would look like this:
+---------+----------+
| user_id | theme_id |
+---------+----------+
| 1 | 1 |
+---------+----------+
| 12 | 1 |
+---------+----------+
| 14354 | 1 |
+---------+----------+
To 'like' a theme, just insert the user and theme id into the table. The rest is just taking care of the response from the database - giving the user feedback for his try to like something more than once etc.
And of course you should not forget the ability to unlike - so you need to delete from the table again... if you want users to unlike.
First you have to create a new table with following fields (id, user_id, theme_id, status) as you said, maintain the relation between user and theme in that table.
when user like the theme insert a record with status 1 , if user unlike the theme, first check the user_id in the table, if user id is present then just update the status to 0 otherwise insert new entry with status 1.
I have a store where I sell products with duration (expiration time for users).
I have a mysql table for users who look like this
| user_id | user_name | user_password | user_email |
and another one for products :
| product_id | product_name | product_price |
I'm selling two products, so now I'm wondering if should I add two columns in user table so it will look like this .
| user_id | user_name | user_password | user_email | product_one | product_two |
and in those fields put the date of expiration for the users who already bought the products (both of them will be blank by default),
or should I just make a new table for the purchased products and then store the appropriate user_id.
Thanks in advance, any help is appreciated.
The second choice is more like a 3NF (3rd Normal Form). I have some little experience in e-shops (mainly in Opencart) and in my opinion, and from whatever I've already seen, this is how they're working.
In fact, it's far better to have one more table which will hold the 'Orders' and a 'User_Id', and another table that will hold the 'Orders' and the 'Product_Ids' in them.
I'm neither a database nor an e-shop platform expert, but according to my experience, I'd go with the second one.
EDIT
I'm editing my current answer to add an example. So, you already have two tables, one for users (customers) and one for products. These two table are (as already mentioned) the following (I don't know the actual table names, so I'll put mine).
table 'users':
| user_id | user_name | user_password | user_email |
table 'products':
| product_id | product_name | product_price |
So, my suggestion is to introduce a new entity (let's name that entity 'order') and create a table that will contains each order matched with the user that made it. So the 'orders' table will be something like this:
| order_id | user_id |
Then you will have another table that will match each order with a product_id. In this table you can have also your 'expiration time' field. A sample of such table is the following:
table 'order_products':
| order_id | product_id | product_exp_date |
However, tha last table has a flaw: it has not a PRIMARY KEY. You have to be a little creative here and import a field in order to hold a primary key, such as order_product_id, which will hold a UNIQUE identifier for each separate product in each separate order. But you'll have to find a way on how to do this.
Hope this clarified my thought.
You want a separate table, which I will name users_products. This will allow you to add products. It's generally more flexible.
It will have these columns
user_id
product_id
expiration
You can find what current products a user possesses like this:
select u.user_name, u.user_email, p.product_name
from users u
left join users_products up on u.user_id = p.user_id
left join products p on up.product_id = p.product_id
and p.expiration >= NOW()
The primary key of your users_products table should be a compound key made of all three columns.
When you sell a user with ID 123 the product with id 321, expiring in 30 days, you represent that in your database with this query.
INSERT INTO users_products
(user_id, product_id, expiration)
VALUES ( 123, 321, NOW() + INTERVAL 30 DAY)
i have a small problem.
Table (user_table)
id | username | name | password
Table (newsletter)
id | date
Table (newsletter_posts) <-- This table isn't very important for my problem.
The user_table is flexible, that means, sometimes i create new users, sometimes i delete users.
The newsletter table is also flexible.
This month
1 | 12345678
Next month
2 | 23456789
and so on...
But how can i create a read/unread table for all newsletter and all users. I have around 100 users and 12 newsletter per year.
Greetings
Dennis
You create a table that relates the newsletter table to the user table.
newsletter_user
----------------
id
user_id
newsletter_id
created_date
Existence of a row should occur (insert) when a user reads a newsletter. If there is no row, the user hasn't read the newsletter. Create a unique index on user_id,newsletter_id.
Just create a mapping table. You can name it newsletter_users_log. It can have columns like:
id -> BIGINT auto increment
newsletter_id -> foreign key to newsletter table
user_id -> foreign key to users table
date_sent -> DateTime
You should make a table that has
user id | newsletter id | status
Then you can query a newsletter to see who has read it or a user to see what newsletters they have read
If you want you can also add in some date fields, say for date read if you want to track that data.
I am making a notification system so that when users in a group perform an action, it will notify all the other users in the group. I want the notification to be marked "read" or "unread" for each user of the group. With that, I can easily retreive any unread notification for a user and display it. I am think about creating a notification table that have the following fields.
+----------------------+
| notification |
+----------------------+
| id |
| userid |
| content |
| status (read/unread) |
| time |
+----------------------+
My question is:
Whether it is the correct way of making the system? As it means that when there is 1,000 users in a group, then I have to insert 1,000 rows to the table. If not, what is the better way of doing this?
If it is the way to do this, how can I write the php/mysql codes to do the looping of inserting the rows?
Thanks!
A better way of doing that would be to separate the notification from the user, by doing the following:
Table Notification
------------------
not_id
time content
Table User
----------
u_id
Table NotificationStatus
------------------------
id
u_id
not_id
bool read
That way you have to save each notification only one, what makes it easier to modify/edit notifications
Consider the following data structure:
Table: Events
----------------
event_id
user_id (foreign key to users table)
action_id (foreign key to actions table)
time_stamp
Table: Log
----------------
user_id (foreign key to users table)
event_id (foreign key to events table)
time_stamp
The logic should be that all events are considered unread by user X unless Log table contains the event_id for that user
Actions table may have many types of actions.
You will be able to count and notify all users how many other users have "recieved" the action by querying the log. etc'...
yes..u can do it in this manner..
example: suppose any user "PQP" (user_id=1) is adding a photo then u have to write ur notification query on success of photo adding query (u need to write write query for notification on code wherever u want that point as notification) so your notification table will got new entry as
id = 1
userid =1
content = "Photo Added By User PQP"
status = Unread
time = currenttime
so by this case whenever someone uploads a photo then notification table will got entry in it..
I have a comments section on a website i'd like to streamline a bit if possible so it's not as much of an impact on the database. When a user selects a post, and if it has comments associated with it, it lists the comments. when the comments list, it fetches the username from another table. I store the id for the user in the comments table, and use that id to select the record from the users table. and displays as "user" said:
lets say i have 1000 comments on a post, it will hit the users table 1000 times to grab user names. I think this is probably a bad design. i thought of a few solutions, but don't know what would be recommended in this situation.
should i just be storing the username inside the comments table?
should i store all of the usernames already called in a session array?
put all of the usernames in a file, and call from the file?
or is there another solution that i haven't thought of?
i'm kind of confused. I thought i was doing the right thing by using the IDs in the comment table, and then using it to fetch the username, but after reading about a million posts on using less impact on the database, i'm starting to question myself.
WOW, thanks for all of the useful answers. here is the table scheme, i don't know why i didn't put in in originally.
comments table for jokes:
id | author_id | joke_id | date_created | body
---+-----------+---------+--------------+-----
1 | 3 | 2 | 2011-06-12 | this is a comment
and for the users:
id | user_name | password | email | date_joined | visible
---+-----------+----------+-------+-------------+---------
3 | booboo | password | email | todays_date | 1
This is what JOINs are for - so that you can run a single query and efficiently get the combined information from multiple tables. E.g.:
SELECT comments.id, comments.content, users.name
FROM comments
JOIN users ON comments.user = users.id
WHERE comments.id in (1,2,3)
would look up the 3 comments with id 1, 2, and 3, plus also get the username of each commenter, and return rows that looked like this:
comments.id | comments.content | users.name
------------+-------------------+---------
1 | "First comment." | "Poster1"
2 | "Second comment." | "Poster2"
3 | "Third comment." | "Poster3"
It sounds like you have a userID field in your comments table, but need to look up the username, correct? If so, a JOIN would be the best solution.
Something like:
SELECT *
FROM `comments`
LEFT JOIN `users` ON `users`.`id` = `comments`.`userid`
WHERE `postid`='1'
To read more on joins and their endless possibilities, read up here
SELECT * FROM comments LEFT JOIN users ON comments.posterid = users.id
Google for LEFT JOIN for more info :)
Do you allow the same username to be used more than once? If not, then I would use the username field as the PK of your users table and store that in the commentstable as the FK. That'll solve your issue nicely.
If changing the PK of your users table is too much of an issue, then just store the username in the comments section since you can still use that select a single record from your users table.