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
I am new in Laravel, I want to have like button on my website
My Post Table:
post_id | body | created_at
My like table:
like_id | user_id | post_id | timestamp
Questions:
1-How to count likes in Laravel?
2-Is my database structure true or not?
3-I am going to have reputation (Like stackoverflow), Should I save that republication in one field in user table or it has different structure?
You can count results with Laravel using count() method. For
example to count all likes in the table:
// Eloquent + Query Builder
$likes = Likes::all()->count();
// Query Builder
$likes = DB::table('likes')->count();
You might want to look at the aggregation methods Laravel offers.
The structure of the two tables you showed looks fine. One thing to consider is what should happen to respective likes when a user or a post gets deleted (ON DELETE ...)
You could put reputation field in the user table, but the cleaner way
to do it is to create separate table for reputation with a foreign
key to user ID.
I would add the total like count to the post table as well. If you don't add it you need to perform sum() queries all the time, which might put too much load on your database (depending on the numver of visits on your site, etc).
You can save the reputation in the user table. You probably want to add something like your like table though. Users for sure want to know why they received some more reputation.
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 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
I have a MYSQL Db that has a PROFILE-TABLE as well as a KEYWORD-TABLE which holds profiles and the other holds keywords associated with those categories.
Profile-Table
UserID
UserName
UserDept
UserPhoto
UserKeyword > indexes KeywordName (from Keyword-Table)
UserAssociations
Keyword-Table
KeyID
KeywordName
I need to make an association with the categories/keywords.
I want to add a hidden field (UserAssociations) onto my profile form which will display a hidden association where as when you click on a category via a link on the page, it will index first those that are associated. I have written this in PHP and use MYSQLI database.
I have never created associations before needing this. What would be the easiest way to achieve this functionality?
From what I gather, you wish to associate a user profile with keyword. What you need is another table to represent the relationship, something like this:
profile_keywords ( <UserID>, <KeyID> )
Hence, if UserID 4 has associated himself with keyword ID 3, you would have an entry in profile_keywords like this:
UserID, KeyID
---------------
3 4
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have database with a user table like so:
table users:
user_id (int)
user_name (varchar)
etc..
This user will be able to fill in a couple of requirements like:
Minimal Salary (int)
Has driver's license (bool)
My other demands (text)
The return value of the User->get(user_id); must be something like this:
user_id: 1,
user_name: 'John Doe',
user_requirements: {
minimal_salary: 2000,
drivers_license: true,
demands: 'These are my demands..'
}
What will be the best way to store this in a Database?
I know you can use a 1 on 1 relation. (it will cost a join or seperate query)
You can store it all in 1 table. (it will cost some tweaking in de code)
You can normalize this in to many to many relation with a type (int/bool/text) in the requirements table.
EDIT
NOTE: I already have 25 columns in the user table, so would it make any difference if I add 3 till 6 columns of demands? For the eye it will get a lot of information in 1 table.
Use only one table to store this data, as i can not see if there is any complexity:
Option 1: (Use only one table)
|--------|-----------|----------------|-----------------|------------------------|
user_id user_name minimal_salary drivers_license demands
|--------|-----------|----------------|-----------------|------------------------|
1 John Doe 2000 true These are my demands..
|--------|-----------|----------------|-----------------|------------------------|
Option 2: If the parameters are more for user requirements then you can make two tables one for users and other for requirements and you can have user_id as foriegn id in the other table. and then can use a join to retrieve the records.
Hope this helps.
Unless you provide the ability to let the user specify their own fields, I see no reason why you should break the information into a separate table. All of those information fields apply to a single, distinct user.
Since there is no data that is common for other users, you can store it in one table.
If the demands for instance would be selected out of a list then I would suggest to store that possible list entries in a seperate table.
If you just don't need every field all the time, then select only the fields you need
don't do
select * from users where user_id = 123
do
select minimal_salary, drivers_license from users where user_id = 123
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 7 years ago.
Improve this question
I am creating an app similar to Instagram. I have a photos table with a likers columns, showing which user_ids have liked a photo. For example, if user_id 1 and 5 like photo_id 51, then photo_id 51's likers column will show 1 5. As seen, the user_ids are separated by spaces. Now, like Instagram, I want to be able to show which username's are liking a specific photo. For this, I need to be able to get all the user_ids from the likers column separately. Can anyone help me with how to do this, or suggest an alternative way?
You're approaching this the wrong way. You almost certainly don't want to store multiple pieces of data in one field. You want to have something like this:
Table: User
- id
- blah blah
Table: Photo
- id
- blah blah
Table: Like
- user_id
- photo_id
This will allow you write very flexible queries, including what you described:
SELECT u.id
FROM User AS u
JOIN Like AS li ON li.user_id = u.id
WHERE li.photo_id = $current_photo_id
This is a topic known as database normalization. Please read more about it if you want your application to succeed.