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.
Related
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.
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'm making an online game for a mounth i guess. I made user profiles, forget password, manage your account pages. And when they enter the game they can see their names and some information abut each other. Never mind of that.
Now, i need to do items for each users. So, here is my mysql table:
user_id | name | email | password | color | items | head | face | body | hand | feet | created
But i can add just one value into items col. How can i add all the item id's the user have? Please someone help!!!
You need a second table. Remove the "items" field from this table and create a new table called Items. In it you will have:
primaryKey | user_id | item
Then to get every item a given user has, you perform a SQL SELECT WHERE user_id=#id and iterate over the results.
There is a one to many relationship between the user and the number of items the user can have. You need to create another table with the following columns
user_id
item_id
item_desc
and store the item information there
You can store the ids as serialised arrays or create an user_item table.
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 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..