I have really dumb question...,
for what are exactly relationships in databases?
If I selecting data from two tables for example:
SELECT Orders.OrderID, Customers.CustomerName, Orders.OrderDate
FROM Orders
INNER JOIN Customers ON Orders.CustomerID=Customers.CustomerID;
In query is exactly specified the columns of what tables will be connected to each other.
Result will be same, no matter if I use foreign keys.
Maybe I am not enough good to find answer, but everywhere is explained HOW to use them, but not WHY I should use them.
PS.: Sorry for bad English, google translator did a lot. :)
Relationships in Databases are used to maintain connection between two entities. For example : classes table and Teachers table. a teacher can take more than one class which means there is a one to many relationship here and by separating data into two separate entities help to maintain referential integrity
Related
I have 2 tables that needs to be joined wherein both of them can have as many of the other table.
A resident can have as many as relative and the relative can have as many as resident.
I need your opinion if this is a good way to join them properly. What I've done is I have a separate table that saves their respective ids.
I've attached a picture of reference. Thanks!
table picture
Yes, that is a classic relational implementation for a many-to-many relationship, implemented with an intersection table.
I'm new to Access and trying to understand m:m relationships. I understand how to create the junction table containing a composite primary key. What I'm having trouble with is what to do next.
Tbl1 has tbl1PK, Tbl2 has tbl2PK, and JunctionTbl1_2 has J1PK and J2PK. How do I populate JunctionTbl1_2?
If I want to do a query on the records in Tbl1 and Tbl2, do I actually do the query on the junction table?
I'm just a little lost on how to use the table. Any help would be appreciated.
This sounds a lot like this question I answered recently, Multiple Many-to-Many Relationships (Circular Relationship)
See if that answer gives you enough information for what should go in the tables. Once you have the junction (more technically the many-to-many tables) populated, a query to see which products were created by a specific employee would look something like this:
select p_idpk from product_employee as pe where pe.e_idpk = e.e_idpk
Let us know if you need more direction.
I have three tables: Resumes, Orgs, and Resume2Org. Basically, Resume2Org is my many-to-many relationship table linking Resumes.resume_id to Orgs.org_id (so it only has those two keys in that table).
My question is, is it okay to use that many-to-many relationship table to store other data? My use case: the database is part of a system to sift through incoming resumes. But I've been asked to implement a "marked as read" feature so we can easily get the list of resumes we haven't looked at yet. But since a resume can belong to many different orgs, we only want to mark a resume as read for the org the user/viewer belongs to. I thought, hey, having that flag in Resume2Org would be perfect. Is this a smart approach, or should I create a new table specifically for "marked as read"? All the examples I've seen about many-to-many relationship tables is that those tables are used just for that... linking two tables.
Yes it is okey to have additional fields in a many-to-many table. I think it is the right way to do in your case as you don't need to join additional tables and you save spaces.
I was in a very similar situation last week and I added additional field for that.
I am designing a database for student information. I wish to implement the best practices regarding separate tables and use of Primary and Foreign Keys.
Let's say I have the following tables (High Level):
Users
Student Information
Student Transcripts
Student Records
There will be different users with different levels. Also, the information in Student Info/Transcripts/Records will all have a Foreign Key with the ID that's in Users.
SO, it would be dumb to just clump all the tables into one big table, wouldn't it? Is it a good idea to keep all this information separate and just use Primary/Foreign keys to link things together, as well as maybe Joins? I just personally think a big table would be quite messy and through this way, it allows one to keep similar data together with its own kind.
Thanks for all input on the matter!
I have the following tables created:
Animes(id,title,date), Comics(id,title,date), TVSeries(id,title,season,episode,date)
Some of them have already foreign keys (for one-to-many or many-to-many relations) of directors, genres, articles and so on.
Now i would like to create two more tables Reviews(id,rating,date) and Posts(id,thumbid,articleid,reviewid).
A review is about one Anime and/or Comic TVSerie and vise-versa but properties of a review may be in more than one table. Its the same about a posts.
Is this a typical example of one-to-one relation in separate table or is it more efficient to add more properties to the existing tables?
So more tables and relations or less tables more columns?
Thank you and i hope my question isnt that stupid but im a bit confused.
In my view, It is better to avoid foreign key relationship for one-to-one relationship. It is best suitable for one - many relationships.
I'm not exactly sure what your requirements are, but the choices are as follows:
Have Reviews have 2 columns, either being a foreign key to the applicable table, can be NULL. This is really for when a single review can be about both.
Have a ReviewsComics and ReviewsAnime table. You'd then have all the fields from Reviews in each table (and no Reviews table).
An alternative (2) is to use them in conjunction with a Reviews table, then those 2 tables only has 2 fields which are foreign keys to Reviews and Comics/Anime respectively (thus no direct link between Reviews and Comics/Anime).
Have a base table to which Anime and Comics are linked to 1-to-1 and have reviews link to that table instead.
(Edit) If all the fields are all going to be the same (or similar) for Anime/Comics, you can merge them into a single table and add a type field, indicating Anime/Comics, then the problem goes away. This is similar to the base table option.
EDIT: The 2 reviews tables will probably give the best performance (unless you want to select all reviews for either, often), but with proper indices the performance shouldn't be an issue with any of the above.