This is more of a general question on how I would approach this.
I have a audio player. No data about songs is stored in the database. I would like to use database for counting likes for each song. My question is how would I organize this?
1.
If I list all my songs in database beforehand and add a column for like, then where would I keep track of user ip address? (not sure if there is a better way than using ip address?) So I prevent of same user voting multiple times.
2.
Every time user likes a song I would store {song title, like count, user ip} (maybe something else) in database. But then I would end up with multiple rows of same song with different user ip addresses, so how would I keep track of likes for every song in this case?
No data about songs is stored in the database
If you want to store data about each song, you should probably add a table for the songs.
not sure if there is a better way than using ip address?
If you have a table with user IDs, use that because the same user can log on from different IPs, and different users can log on from the same IP.
As for database structure, what you proposed is probably the right answer. Once you have a table set up for songs, have a dedicated column just for likes to you can retrieve it easily.
If you want to know which user liked which song (and when) then you need to make a new table like you suggested in your second point. This is called a junction-table, and is used for many:many relationships (m:m). There is no unique id. It joins two tables with many keys (users:songs) and stores any relationship between the two.
Every time user likes a song I would store {song title, like count, user ip} (maybe something else) in database. But then I would end up with multiple rows of same song with different user ip addresses, so how would I keep track of likes for every song in this case?
Even if you end up with many rows of the same song, they are all unique since each has a different user liking it (and vice-versa, you can get all the songs a specific user liked). You wouldn't need to store a like-count in here, since you can just count the number of records in the database. {song title, user id, datestamp} would be fine.
Related
So I have two different tables, a users table and an articles table. The idea is to allow a user to rate an article, but only allow them to rate it once (possible change their existing rating too but I can come to that conclusion later).
As of now I just have the update value working to allow them to rate the article, but of course a user can rate an article as many times as they want.
To give you an idea of how I have everything working, when a user logins in, a session is created with their user information. So when they go to rate an article, I have the ability to check the user, I just don't know how to stop them from rating if they have already rated a specific article.
The user table consists of among other things their username and their unique ID
and the article table consists among other things the article contents, the article unique ID, and the articles rating.
I had some really sloppy ideas like when the user rates an article their ID gets stored into the articles row in some kind of "users who have rated" column, and then I can do a for loop or something to siphon out all the user IDs and then check if their ID exists in that articles entry but then each article would have a row with possibly hundreds or thousands of userIDs on it and there seems like there would be a more elegant way.
Any help or direction is appreciated :)
Create a UserRatings table which has foreign keys to the users table and the articles table, and stores a row linking the user to the article, and the rating they gave it and when it occurred.
Then if a user tried to rate it again you just check this table for the user ID/article ID combination before allowing it.
And then if you wanted got can do things like show the user a list of articles they have previously rated, etc
I created Users table.
After the user registered, The system enter his address, phone, city and more personal details to Users table.
There is another table, called Contacts, there the user add another people details.
Now, if there is Contacts table, How better to save the personal details of the user in Users table? in one json column that contains all the user personal details, or in normal columns (address, phone, city)?
I just do not want to happen a situation of multiple data.
I think separate columns for each field will be the better option!
Well, it would of course be easy to just store it as JSON, but that way, it could be a bit messy to search for certain stuff in the database (say you wish to check all users from a given city for example).
When it comes to user information, I always find the best way to do this is to store only login vital data and the base info in a users table.
Something like:
id | email | password
And then have different tables for the other data.
Name and such (which a user only has one of (of course one could have multiple names, but I usually only store first and last names)) could be stored in a user_information table, which is in a one to one relation with the user (foreign key for the user_id so that it can be quickly fetched when needed).
When it comes to address and phone number, a user could actually have multiple.
I understand that its possible that your system/app is only supposed to support one address or one phone number and the like, but its always nice to make it "right" from the start, so that its easy to just let the user add multiple of them whenever the need is there.
That way, you would have a few different tables:
users
user_information
addresses
phone_numbers
and so on...
The user_information, addresses and phone_numbers would preferably all have a user_id column which would be used for a foreign key to point at the user who owns it. And if you wish to make it possible to use the same tables for contacts, a contact_id could be added too (and a foreign key to point to the contact).
I am currently working on a system that would allow users to add additional custom fields for the contacts that they add.
I wondered what is the best and most efficient approach to add such ability?
Right now what I was thinking was to have 1 table per users (with foreign keys to a "main" contacts table) and then adding a column for each custom fields that the user adds (since I don't expect to have more then 100-200 users per database shards [sharding is easy since every users never see each-other's content in this system]), although I am not 100% sure that this would be the right solution for such problems.
Maybe you could try to have one separated table to store a reference to the user, plus the field name and value, this way you will be able to have lots of custom fields.
If you go with Boyce-Codd, you separate the information and store them into a table.
Means one table for all users with a foreign key.
One table per user would lead to hundreds or more tables with possible repeated information.
You need to have one table named USERS that stores the id of a user and fixed info you might want. Then, you could have a CONTACT table, that stores the type of contact user might create, and one matching table USER_CONTACT that matches the user unique id with the id of the contact that was created.
With this, you could have advanced data mining on all the information stored, like nowing how many contacts each user created, who created more, etc...
I have a site that allows users to vote on images. Each image has a unique id number. For voting restriction purposes, I'd like to keep track of what each user has liked. How would I go about setting up a row in the USERS table that holds all the different id numbers of the images liked by this particular user?
You should not have all this information in your users table. I persume that you have one table with all your images and one with all your users. Create a table called "user_image_like" for example. And store "user_id" and "image_id". When the user presses like on the image your script will add "user_id" and "image_id" to the table.
When you wan't to see all images liked by a user you can easly get this by a simple sql query.
If you want to store such information in one table and in one field, I have the answer for you.
You can use either ways:
Store the IDs in a CSV format. When you fetch these values you can deal with them as you deal with a CSV file.
Store the IDs in an XML format. Then, you deal with it as any other XML file.
Regards,
This is a Many to Many relation. i.e. one user can like multiple Images and one image can be liked by multiple users.
According to normalization standards you should use these relation in separate table with user_id and image_id. whenever user like an image add a row to this table.
If you still want to store it in single table (users) then store ids in CSV format. be sure to store only unique image ids for each row.
Check this article
http://www.tonymarston.net/php-mysql/many-to-many.html
I am building a database in MySQL that will be accessed by PHP scripts. I have a table that is the activity stream. This includes everything that goes on on the website (following of many different things, liking, upvoting etc.). From this activity stream I am going to run an algorithm for each user depending on their activity and display relevant activity. Should I create another table that stores the activity for each user once the algorithm has been run on the activity or should I run the algorithm on the activity table every time the user accesses the site?
UPDATE:(this is what is above except rephrased hopefully in an easier to understand way)
I have a database table called activity. This table creates a new row every time an action is performed by a user on the website.
Every time a user logs in I am going to run an algorithm on the new rows (since the users last login) in the table (activity) that apply to them. For example if the user is following a user who upvoted a post in the activity stream that post will be displayed when the user logs in. I want the ability for the user to be able to access previous content applying to them. Would it be easiest to create another table that saved the rows that have already been run over with the algorithm except attached to individual users names? (a row can apply to multiple different users)
I would start with a single table and appropriate indexes. Using a union statement, you can perform several queries (using different indexes) and then mash all the results together.
As an example, lets assume that you are friends with user 37, 42, and 56, and you are interested in basketball and knitting. And, lets assume you have an index on user_id and an index on subject. This query should be quite performant.
SELECT * FROM activity WHERE user_id IN (37, 42, 56)
UNION DISTINCT
SELECT * FROM activity WHERE subject IN ("basketball", "knitting")
ORDER BY created
LIMIT 50
I would recommend tracking your user specific activities in a separate table and then upon login you could show all user activities that relate to them more easily. ie. So if a user is say big into baseball and hockey you could retrieve that from their recent activity, then got to your everything activities table and grab relevant items from it.