I am trying to make a database of Users and Movies. Then I want to allow users to click on a movie and mark it as "watched".
What would be the best way to go about structuring this. I mean, could I simply have a table called "Watched" and simply link the UserId to the MovieId in that table to signify that the user has watched that particular movie. This would mean that every instance of a movie being watched will need a record in the table, right? It seems like it could end up taking up ALOT of space in the database.
Is there not an easier way to do this? Sorry if it sounds abit vague. I'm thinking its kind of similar to "friends" on facebook. Would there be a table somewhere where each instance of a friendship occuring is recorded as a record, or is there a way of simply having a list of friends lookup, or something, i don't know... any help much appreciated, thanks!
Your suggestion is correct, using table called "Watched" and simply link the UserId to the MovieId in that table.
In this way, you will have a normalised database, with one-to-many relationship on both sides, toward the "Movies" and "Users" tables.
It will also save you performance cost also when retrieving data later, in case your database becomes a really large one.
You need a user table, movies table, friendship_match table and if you want to record which movie watched at which time, a watch table (with this one you can also display watch history for users)
You have to have a table for friendship because it will contain requests also. If a person adds someone, it doesnt mean the other person will accept it. Other than this, it will take really take a long time if you query the whole users table.
Related
I'm creating a small community using the Symfony2 Framework and backboneJS.
When I took a look at the database today I realized that it might be wrong to store all images using this schema.
ImageTable
Id
Title
Owner
Description
Url
So when a user logs in and wants to have a look at his own images, I just loop through all images where owner == currentuser.
Is this a bad practice?
The more owners I have the longer the query its going to take, right?
I'm asking since it might take a week to restructure the whole website database and I don't want to fix what might not be broken.
I know a solution might be to set a manytomany relationship between the current user table and an own image table, but is it worth the effort?
As far as I can see, this is as normalized as it gets for your scenario. A many to many relationship is not what you are looking for, since a user may have multiple images, but an image can't have multiple owners (or can they?).
So if the Owner is a foreign key for the table user you are good.
I'm looking for a good way say, to save favorite images for a specific user in the database. Or if I have a movie, I want to display related movies, you get the idea. I don't know how to do it on a database level (phpmyadmin). My idea so far is if I have a table named Users, I add a column in it named Favorites, in which I enter every ID or Name of the favorite item. The problem is that the content in this column may grow a lot more than I expect, and I don't feel this is a good way to do it. So how do I go about this?
Try having a table called "Favourites" with a column called UserID and another column for the ID or name of the favourited items. Then you would have one row for each user/favourite pair.
This allows you to have many favourites per user, and you can maintain arbitrary metadata about each favourited item (for example the time and which it was selected as the favourite).
You can also answer questions like "Which users have favourited a given item?" with this approach.
This is standard DB modelling for this type of problem.
currently Im working on a project that, at first glance, will require many tables in a database. Most of the tables are fairly straightforward however I do have an issue. One of the tables will be a list of members for the website, things like username, password, contact info, bio, education, etc will be included. This is a simple design, however, there is also a need for each member to have their availability entered and store in the database as well. Availability is defined as a date and time range. Like available on 4/5/2011 from 1pm to 6pm EST, or NOT available every friday after 8pm EST. For a single user, this could be a table on its own, but for many users, Im not sure how to go about organizing the data in a manageable fashion. First thought would be to have code to create a table for each user, but that could mean alot of tables in the database in addition to the few I have for other site functions. Logically i could use the username appended to Avail_ or something for the table name ie: Avail_UserBob and then query that as needed. But im curious if anyone can think of a better option than having the potential of hundreds of tables in a single database.
edit
So general agreement would be to have a table for members, unique key being ID for instance. Then have a second table for availability (date, start time, end time, boolean for available or not, and id of member this applies to). Django might sound nice and work well, but i dont have the time to spend learning another framework while working on this project. The 2 table method seems plausable but Im worried about the extra coding required for features that will utilize the availability times to A) build a calender like page to add, edit, or remove entered values, and B) match availabilities with entries from another table that lists games. While I might have more coding, I can live with that as long as the database is sound, functional, and not so messy. Thanks for the input guys.
Not to sound like a troll, but you should take a look into using a web framework to build most of this for you. I'd suggest taking a look at Django. With it you can define the type of fields you wish to store (and how they relate) and Django builds all the SQL statements to make it so. You get a nice admin interface for free so staff can login and add/edit/etc.
You also don't have to worry about building the login/auth/change password, etc. forms. all that session stuff is taken care of by Django. You get to focus on what makes your project/app unique.
And it allow you to build your project really, really fast.
djangoproject.org
I don't have any other framework suggestions that meet your needs. I do... but I think Django will fit the bill.
Create a table to store users. Use its primary key as foreign key in other tables.
The databases are written to hold many many rows in a table. There are not optimized for table creation. So it is not a good idea to create a new table for each user. Instead give each user an unique identifier and put the availability in a separate table. Provide an additional flag to make an entry valid or invalid.
Create a table of users; then create a table of availabilities per user. Don't try to cram availabilities into the user table: that will guarantee giant grief for you later on; and you'll find you have to create an availabilities table then.
Google database normalization to get an idea why.
Take it as truth from one who has suffered such self-inflicted grief :-)
This isn't much of a coding question as opposed to seeking help on going down the right path. So, I have my users set up with username, password, email, posts, & id. The basic forum stuff. But, if I were to add more, say some games in the website that you play and store data with your forum account (being your account for the whole website, in other words), would it be wiser to add those fields to the existing table (i.e.: game1_money) or make another table for each individual side project, then create and link it to each user upon starting the "game" or whatever it is?
If I'm too vague, tell me and I'll try to clarify.
Use separate tables and then a left join when you want the data for the specific game or application. Then if 10% of the users are signed up for the game you don't waste the table space for the other 90%. You also don't need to keep fiddling with the user table.
Anonymous,
Always try to keep your primary table clean and relate everything back to a unique, individual index. In this case, whether you add games, comments, documents, whatever...user User_ID (for example) as the related index field that points back to your main users table.
Here's a good reference on building normalized tables
http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html
Don't store that information in the Users table. Normalise into separate tables.
Create a separate table, say GameSavedInfo, to store this information and reference the users ID from the user table.
I would also create a GameDetails table and use its Id in the GameSavedInfo table.
I have my own theories on the best way to do this, but I think its a common topic and I'd be interested in the different methods people use. Here goes
Whats the best way to deal with many-to-many join tables, particularly as far as naming them goes, what to do when you need to add extra information to the relationship, and what to do whene there are multiple relationships between two tables?
Lets say you have two tables, Users and Events and need to store the attendees. So you create EventAttendees table. Then a requirement comes up to store the organisers. Should you
create an EventOrganisers table, so each new relationship is modelled with a join table
or
rename EventAttendees to UserEventRelationship (or some other name, like User2Event or UserEventMap or UserToEvent), and an IsAttending column and a IsOrganiser column i.e. You have a single table which you store all relationship info between two attendees
or
a bit of both (really?)
or
something else entirely?
Thoughts?
The easy answer to a generic question like this is, as always, "It all depends on the details".
But in general, I try to create fewer tables when this can be done without abusing the data definitions unduly. So in your example, I would probably add an isOrganizer column to the table, or maybe an attendeeType to allow for easy future expansion from audience/organizer to audience/organizer/speaker/caterer or whatever may be needed. Creating an extra table with essentially identical columns, where the table name is in effect a flag identifying the "attendee type", seems to me the wrong way to go both from a pristine design perspective and also from a practical point of view.
A single table is more flexible. With one table and a type field, if we want to know just the organizers -- like when we're sending invitations to a planning meaning -- fine, we write "select userid from userevent where eventid=? and attendeetype='O'". If we want to know everyone who will be there -- like when we're printing name cards for the lunch tables -- we just don't include the attendeetype test.
But suppose we have two tables. Then if we want just the organizers, okay, that's easy, join on the organizer table. But if we want both organizers and audience, then we have to do a union, which makes for more complicated queries and is usually slow. And if you're thinking, What's the big deal doing a union?, note that there may be more to the query. Perhaps a person can have multiple phone numbers and we care about this, so the query is not just joining user and eventAttendee but also phone. Maybe we want to know if they've attended previous conferences because we give special deals to "alumni", so we have to join in eventAttendee a second time, etc etc. A ten-table join with a union can get very messy and confusing to read.