Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Hi i am working on site where users login to read articles, every articles is based in a category. so i want to display on the 'user home page' the category and article the last have visited/read. This counts for multiple category, so it neets to display "category 'a' read 12 of 20 articles 'click here to continue reading' " If someone can help me or send me in the right direction, any help / info is very much appreciated. Thank you
There's no special utility that can do something like that for you, if that's what you're thinking. What you will need to do is create a table in MySQL that stores a list of articles read by your users. Maybe a table with just user_id and article_id, together making up the primary key. INSERT IGNORE when a user visits an article, and when you want to get how many articles have been read, you can SELECT COUNT(*) FROM table WHERE user_id = ?
SELECT COUNT(*) FROM table WHERE user_id = ? AND article_id IN (SELECT id FROM articles WHERE category_id = ?)
The query above would let you get the number of articles that the specified user has viewed within the specified category, assuming you have it set up like this.
You also mentioned that you want to be able to select the most recent article or category the user has read. To do that, you can add a timestamp field to the new table you created. Another way is to add an auto_increment field and grab the biggest one.
Just an idea. You can create an extra table , lets call it user_read and store which user read which article.
Table user_read
user_id
article_id
I assume you know which article belongs to each category, therefor you can count how many articles in each category the user has read.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am trying to insert a column in a database table automatically using a variable.
I have a table named tbl_category, I want to let the user choose the sub category field by their own choice. So, from the dashboard, the user will insert 3/4 (or how many fields they would like to create) sub category fields.
I will take this value as $insert_sub_cat_count. So, when this info will hit the function named function save_category_info($data), the function will receive the value $insert_sub_cat_count as $data.
After that, this info have to implement in the table tbl_category and add 3/4 fields automatically according to the value $data.
If the user inputs 2, this will insert two columns automatically:
If the user inputs 3, this will insert 3 columns:
Is this possible? I don't know how to extend columns automatically or if there's any other way to do so.
This is a bad idea from the very start. As Raymond Nijland said above ("the same column names with increment are a SQL anti pattern.. you should check table normalization instead"), you shouldn't allow users to create columns with their desired name in your database. You should have the following tables:
user - id, name
categories - id, id_user, name
subcategories - id, id_category, id_user, name
So you will be able to link the category and subcategory to the user that created it. You don't need to create a separate column for each user.
If you're worried about speed you should add index for the subcategories table, for the column: id_user. In this way the search will work fast enough.
Insert is used to insert variables into an already existing column, you need to first create your column before filling it:
ALTER TABLE `tbl_category` ADD `sub_category_one` VARCHAR(100) NOT NULL;
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm designing a database for social media which is similar to facebook structure. I'm using MySQL. The main goal for our database is the performance, it must handle a high number of requests.
I have a list of users, friends, posts on wall, comments and likes.
Q1- for users, I have several types of users, I have normal users, supervisors and admin. for that table, I'm thinking to define one parent user table and then inherit the information, but at the same time the fields are same.
example:
user
=============
id
username
password
email
isAtcive
country
noraml_user
===============
name
..
..
user_id
supervisor
==============
name
..
..
user_id
admin
=======
name
..
..
user_id
I considered this method because of performance, so instead of searching for single user using user type in (one million users as an example), I search for (300K users in table supervisor). Am I right?
Q2- I have likes for the posts and comments. here is my design
posts
==========
id
content
comments
==========
id
content
post_id
posts_likes
==========
id
post_id
user_id
comment_likes
==========
id
comment_id
user_id
Do you think this is correct, or I just make one table for likes such as the following
likes
=========
id
post_id(nullable)
comment_id(nullable)
user_id
what is best approach?
Q3- Could you provide me some tips to be considered for designing social network database?
Thanks :)
Q1: You shouldn't create separate tables for different user types. In fact, you should have a user role column in a common user table. This role would then define what the user can do. The whole point of indexes is to efficiently find subsets of a table.
Q2: Again, you'll probably find that you have content and likes (or maybe even "reactions"). Unless there's a specific reason to keep posts special, they're really just content that has no parent.
Q3: Yeah, so that's way to o broad a question for a site like this.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
At the moment I create a blog system with php. The admin can create x posts, and under every post should be a comment function. How can I realize something like that? I dont know the structure of the databse, because it must be many tables (for each post(?)). Maybe someone of you have a good link. I searched already but have found nothing for my problem.
You don't need many tables. You could have a table for the posts like this:
id INT(10)
title TEXT
content TEXT
And a table for the comments, like this:
id INT(10)
postId INT(10) // this links to the column post.id
content TEXT
Of course, you can add more columns to both tables if necessary, for example to add timestamps, etc.
Now, when you have a post with id 7, you make sure that all the comments to that post get postId 7. That way, when you display post 7 on your website, you can search for all the rows in the comment table with postId=7, and display exactly those comments that are linked to that post.
I've simplified this example. To optimise the tables you could add indices, primary keys, etc.
#Skeptar, there quite a number of ways you can achieve this. Let me suggest one to you.
Users table: (very obvious)
Columns: user_id (INTEGER(n) PRIMARY KEY), username (VARCHAR(n)), password (VARCHAR(32) for md5), level (INTEGER Example: 1 for admin, 3 for regular user)
Posts:
Columns: post_id (INTEGER(n) PRIMARY KEY), post_title (VARCHAR(n)), post (TEXT), user_id (INTEGER(n))
Comments:
Columns: comment_id (INTEGER(n)), comment(TEXT), post_id,(INTEGER FOREIGN KEY REFERENCES post(post_ID)) user_id(INTEGER(n) FOREIGN KEY REFERENCES users(user_id))
Now, I believe you have a means of allowing both levels (admin and regular) of users to register into your system.
When inserting, you take the post title and the actual post and with the help of some user identification mechanism like SESSIONS, you get the user_id and insert them into to post table.
Then for each comment, when inserting, you fetch the post_id of the post on which the user is commenting and insert that into the comment table along with the comment and the user_id.
When you want to fetch all posts, that's fairly easy.
When you want to fetch all comments for a particular post, you take the post_id of that post to the comments table as such:
SELECT * FROM comments C, posts P WHERE C.post_id = C.post_id;
Since you inserted the user_id against each post and comment, similarly, you can fetch the corresponding user information for each comment as such:
SELECT U.username FROM comments C, users U Where C.user_id = U.user_id
Remember, this is only to give you and idea and not to be taken as a complete working solution. I wrote this off head and could have some errors.
Also, where I indicated in bracket n (INTEGER(n)), it means you need to replace n with the desired columns size. Hope it helps.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
How does Facebook limit one like per person per post? I'm implementing something similar for a site but I'm not sure how to approach this correctly. Should I create a table for every single post and just have rows recording which users have voted on a particular post?
Is creating as many tables as you have posts bad? Is there a better way to do this?
A better example is how Stack Overflow keeps track of which answers and questions every user has voted on. When you go to a question you've already voted on, it shows your vote. How does it do this efficiently?
I've already tried researching this and I didn't find anything that explains a way to do this.
Consider having a table
POSTS (POST_ID, POST_CONTENT, POST_AUTHOR)
and a table
POSTS_LIKES (POST_ID, LIKED_BY)
Yes, definitely do not have one table per post, that would be a horrible design.
Either show or don't show the like button based on whether the currently logged in user appears in the POST_LIKES table as the LIKED_BY value for the given POST_ID (should be a simple query)
Have a table for users (PK=UserId).
Have a table for posts (PK=PostId).
Have a table for Likes (Likes.PK = FK Users.UserId and FK Posts.PostId).
When the user clicks on "like" create an entry in the Likes table. Since there's only one entry PK for Likes is PK for Users + PK for Posts, it guarantees there can only be one like per post.
Create a votes table in your DB. and make user_id and post_id combined unique index. So users won't be able to give more than one vote per post.
Votes
----------
int vote_id
int user_id
int post_id
int vote_type_id // For example 1 = UPVOTE 2 = DOWNVOTE
I'll add a 'theyvevoted' column to the posts table, and fill it with:
' ' . $userid . ' '
So I can do an strstr( $post['theyvevoted'], ' ' . $userid . ' ' ) later.
More efficient than having an extra table IMO if most posts will have "votes" attached.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Let' say I Have 2 tables, webpage table, and a keywords table. It's a many to many relationshiop, right? One webpage can contain more than one keyword, and one keyword can be part of more than one webpage.
Webpage table contain id field as PK, and few other fields. Keywords table contain id as a PK, and also a few other fields. Third table, a child table, should contain id fields from both parent tables? Is it posible to track many to many relationship, with no foreign keys, just declaring this 2 id fields in child table as UNIQUE?
With or without FK's, when inserting new keywords for example through PHP, how should I refer, to which webpage this new keyword belongs, webpage id in a webpage table, or a id in a child table?
I would do something like this...
Table1
Table_WebPage
PageID, PageName, Url,...........
Table2
Table_KeyWords
WordID, Word, .........
Table3
Table_PageKeyWords
ID, PageID, WordID
Dont know why you want to do it without FK, Having FKs will enforce the data integrity and stop garbage data coming into your tables.