2011-09-07, 03:34
A 1-to-N relationship is basically when you have one "parent" record, and a bunch of child ones. That's really an awful explanation, but I think this example will make up for it:
Each user has N instant messaging handles.
This would lead to a table structure like this:
In that example, each user has 0 to N instant messaging handles. If that's not more clear, please say so and I'll try to explain a bit more. I've found this is the type of stuff you learn best by doing things and making mistakes, so it's a bit tough to explain.
This might help you: http://www.phlonx.com/resources/nf3/ , even if it only gives you the correct terminology to look at other resources.
My reasoning behind having one table is you are never going to have one entry in 'movies' with two or more entries in 'moviedata'. The fact that they share a primary key would be a good indication to me that they should be in the same table.
As far as when you were populating them, I had just assumed you had two tables because you were retrieving data for them at two different times. It really has no bearing as to your tables.
I think I understand what you were intending with having one table with prime movies, and one with non-prime, but couldn't you accomplish the same with having a primeAvailable bool in the moviedata table?
Each user has N instant messaging handles.
This would lead to a table structure like this:
Code:
create table users
(
username varchar(20)
, primary key (username)
);
create table im_handles
(
username varchar(20)
,imtype enum('aim','icq','irc','msn')
,imhandle varchar(20)
,primary key (username, imtype)
)
In that example, each user has 0 to N instant messaging handles. If that's not more clear, please say so and I'll try to explain a bit more. I've found this is the type of stuff you learn best by doing things and making mistakes, so it's a bit tough to explain.
This might help you: http://www.phlonx.com/resources/nf3/ , even if it only gives you the correct terminology to look at other resources.
My reasoning behind having one table is you are never going to have one entry in 'movies' with two or more entries in 'moviedata'. The fact that they share a primary key would be a good indication to me that they should be in the same table.
As far as when you were populating them, I had just assumed you had two tables because you were retrieving data for them at two different times. It really has no bearing as to your tables.
I think I understand what you were intending with having one table with prime movies, and one with non-prime, but couldn't you accomplish the same with having a primeAvailable bool in the moviedata table?