So, this is probably gonna sound like a weird or dumb question.
I have this application that I'm writing, which consists of four tables. Two are 'connected' to one main table, and one last one is connected to one of those two tables. I've included a database diagram to give you a better idea of what I mean.
Now, my goal is to have 'Bedrijfsnaam' from the 'Bedrijven' table into the 'Samenwerkingen' table. Problem is: I can't add more than two foreign keys, so I was assuming that I would have to create a FK in'Contactpersonen' table and pick it from the 'Bedrijven' table. It would basically mean I'd have a JOIN in 'Contactpersonen' table to my 'Bedrijven' table. And then the 'Samenwerkingen' table has a JOIN to the 'Contactpersonen' table and accesses the column from 'Bedrijven'.
Does that make any sense? Hope it does, because I could really use some help making this possible. xD
Since Samenwerkingen has a foreign key to Contactpersonen which is itself related to Bedrijven, you don't need an additional constraint: your data integrity is guaranteed and you can join the two tables.
Your query should look like :
select s.*, b.* from Samenwerkingen s
inner join Contactpersonen c on s.Contactpersonen = c.Contactpersonen
inner join Bedrijven b on c.Bedrijfnaam = b.Bedrijfnaam
Related
I need to brind a lot of columns from several tables using LEFT JOIN. My starting point is the orders table and I bring the vendor name from the "Address_table". Then I add another table with order details and then the shipping information of each order detail.
My problem is that I need to bring a different record from "Address_table" to refer onether id's detailed in shipment table as of "origin_id" and "destination_id".
In other words, "address_id", "origin_id" and "destination_id" are all records from "Address_table". I brought the first one related to the vendor, how can I retrieve the other two?
Example
Thanks in advance
Your question is not exactly clear in terms of the tables and their relationships. It is, however, clear what the problem is. You need to join against the same table twice using different columns.
In order to do that you need to use table aliases. For example, you can do:
select *
from shipment s
left join address_table a on a.address_id = s.origin_id
left join address_table b on b.address_id = s.destination_id
In this example the table address_table is joined twice against the table shipment; the first time we use a as an alias, the second time b. This way you can differentiate how to pick the right columns and make the joins work as you need them to.
I have to two tables, both have a composite primary key:
OrderNr + CustNr
OrderNr + ItemNr
Can I join both tables with the OrderNr and OrderNr which is each a part of a composite primary key?
Yes, but you may find you get rows from each table that repeat as they combine to make a unique combination. This is called a Cartesian product
Table A
OrderNr, CustNr
1,C1
1,C2
2,C1
2,C2
TableB
OrderNr,ItemNr
1,i1
1,i2
SELECT * FROM a JOIN b ON a.OrderNr = b.OrderNr
1,C1,1,i1
1,C1,1,i2
1,C2,1,i1
1,C2,1,i2
This happens because composite primary keys can contain repeated elements so long as the combination of elements is unique. Joining on only one part of the PK, and that part being an element that is repeated (my custnr 1 repeats twice in each table, even though the itemnr and CustNr mean the rows are unique) results in a multiplied resultset - 2 rows from A that are custnr 1, multiplied by 2 rows from B that are custnr 1, gives 4 rows in total
Does it work with the normal/naturla join too?
Normal joins (INNER, LEFT OUTER, RIGHT OUTER, FULL OUTER) will join the rows from two tables or subqueries when the ON condition is valid. The clause in the ON is like a WHERE clause, yes - in that it represents a statement that is true or false (a predicate). If the statement is true, the rows are joined. You don't even have to make it about data from the tables - you can even say a JOIN b ON 1=1 and every rows from A will get joined to every row from B. As commented, primary keys aren't involved in JOINS at all, though primary keys often rely on indexes and those indexes may be used to speed up a join, but they aren't vital to it.
Other joins (CROSS, NATURAL..) exist; a CROSS join is like the 1=1 example above, you don't specify an ON, every row from A is joined to every row from B, by design. NATURAL JOIN is one to avoid using, IMHO - the database will look for column names that are the same in both tables and join on them. The problem is that things can stop working in future if someone adds a column with the same name but different content/meaning to the two tables. No serious production system I've ever come across has used NATURAL join. You can get away with some typing if your columns to join on are named the same, with USING - SELECT * FROM a JOIN b USING (col) - here both A and B have a column called col. USING has some advantages, especially over NATURAL join, in that it doesn't fall apart if another column of the same name as an existing one but it has some detractors too - you can't say USING(col) AND .... Most people just stick to writing ON, and forget USING
NATURAL join also does NOT use primary keys. There is no join style (that I know of) that will look at a foreign key relationship between two tables and use that as the join condition
And then is it true that if I try to join Primary key and foreign key of two tables, that it works like a "where" command?
Hard to understand what you mean by this, but if you mean that A JOIN B ON A.primarykey = B.primary_key_in_a then it'll work out, sure. If you mean A CROSS JOIN B WHERE A.primarykey = B.primary_key_in_a then that will also work, but it's something I'd definitely avoid - no one writes SQLs this way, and the general favoring is to drop use of WHERE to create joining conditions (you do still see people writing the old school way of FROM a,b WHERE a.col=b.col but it's also heavily discouraged), and put them in the ON instead
So, in summary:
SELECT * FROM a JOIN b ON a.col1 = b.col2
Joins all rows from a with all rows from b, where the values in col1 equal the values in col2. No primary keys are needed for any of this to work out
You can join any table if there is/are logical relationship between them
select *
from t1
JOIN t2
on t1.ORderNr = t2.OrderNr
Although if OrderNr cannot provide unicity between tables by itself, your data will be multiplied.
Lets say that you have 2 OrderNr with value 1 on t1 and 5 OrderNr with value 1 on t2, when you join them, you will get 2 x 5 = 10 records.
Your data model is similar to a problem commonly referred to as a "fan trap". (If you had an "order" table keyed solely by OrderNr if would exactly be a fan trap).
Either way, it's the same problem -- the relationship between Order/Customers and Order/Items is ambiguous. You cannot tell which customers ordered which items.
It is technically possible to join these tables -- you can join on any columns regardless of whether they are key columns or not. The problem is that your results will probably not make sense, unless you have more conditions and other tables that you are not telling us about.
For example, a simple join just on t1.OrderNr = t2.OrderNr will return rows indicating every customer related to the order has ordered every item related to the order. If that is what you want, you have no problem here.
I have a three tables as illustrated in the screenshots below:
The primary design objective is to separate the values in the LICENSE_REQ table: TAX, INSURANCE and BENEFIT columns from their description in the LICENSE_REQ_DESC table.
The below query returns the TAX, INSURANCE and BENEFIT columns next to their description from the LICENSE_REQ_DESC table.
Query:
SELECT A.LICENSE_ID,
B.TAX, T.REQ_CODE_DESC,
B.INSURANCE,
I.REQ_CODE_DESC,
B.BENEFIT,
J.REQ_CODE_DESC
FROM BUSINESS A INNER JOIN LICENSE_REQ B ON A.LICENSE_ID = B.LICENSE_ID
LEFT OUTER JOIN LICENSE_REQ_DESC T ON B.TAX = T.REQ_CODE
LEFT OUTER JOIN LICENSE_REQ_DESC I ON B.INSURANCE = I.REQ_CODE
LEFT OUTER JOIN LICENSE_REQ_DESC J ON B.BENEFIT = J.REQ_CODE
Tables:
BUSINESS - Primary Key LICENSE_ID
LICENSE_REQ - Foreign Key LICENSE_ID
LICENSE_REQ_DESC - Primary Key SEQ_NBR
And here is the resultset screenshot:
Is there a more effective and efficient method for separating data from meta data (description) for efficiently querying the desire resultset?
I like your way.
Some developers might create a stored function like get_desc(req_code) and write the SQL as:
SELECT A.LICENSE_ID,
B.TAX,
get_desc(B.TAX) TAX_DESC,
B.INSURANCE,
get_desc(B.INSURANCE) INSURANCE_DESC,
B.BENEFIT,
get_desc(B.BENEFIT) BENEFIT_DESC
FROM BUSINESS A INNER JOIN LICENSE_REQ B ON A.LICENSE_ID = B.LICENSE_ID
But I much prefer the way you've got it. Keep it all in pure-SQL when you can!
There are pro's and con's to the single lookup table method.
The primary pro is that all the translations are in one place, you don't need to go searching hither and yon to find each translation.
The cons are that you end up with larger lookup tables and usually more complex join requirements since there is usually a discriminator column included in the join, and you are limited to having the exact same attributes available for every lookup.
Right now your scheme doesn't include a discriminator column to determine from the contents of LICENSE_REQ_DESC which code value source the description goes with. This can be a problem if for some reason their are REQ_CODE values conflicts between the TAX, INSURANCE, and BENEFIT code columns.
An improved version of your LICENSE_REQ_DESC table would be to:
ALTER TABLE LICENSE_REQ_DESC ADD (REQ_CODE_SOURCE VARCHAR2(15) );
Populate the new column with appropriate values e.g. 'TAX', 'INSURANCE', and 'BENEFIT' then:
ALTER TABLE CODE_LOOKUP MODIFY (REQ_CODE_SOURCE NOT NULL);
ALTER TABLE CODE_LOOKUP ADD CONSTRAINT CODE_LOOKUP_UK UNIQUE
(
REQ_CODE_SOURCE
, REQ_CODE
)
ENABLE;
And finally change your query to use the following joins:
LEFT OUTER JOIN LICENSE_REQ_DESC T ON T.REQ_CODE_SOURCE = 'TAX' AND B.TAX = T.REQ_CODE
LEFT OUTER JOIN LICENSE_REQ_DESC I ON T.REQ_CODE_SOURCE = 'INSURANCE' AND B.INSURANCE = I.REQ_CODE
LEFT OUTER JOIN LICENSE_REQ_DESC J ON T.REQ_CODE_SOURCE = 'BENEFIT' AND B.BENEFIT = J.REQ_CODE
There is some interesting reading here (in the negative):
https://www.simple-talk.com/sql/t-sql-programming/look-up-tables-in-sql-/ (although not everyone agrees with Joe Celko he always goes into depth)
Something to consider is your foreign keys. You can enforce a foreign key to this table but you cannot enforce that a tax transaction record may only use a tax description record.
Foreign keys enforce logic and can assist in generating an efficient query plan. When you are creating foreign keys that don't quite tell the whole story, it appears to indicate a design issue.
Looking ahead: Could this lookup table end up being extended to store many other types of descriptions? Could the distribution of description types be heavily skewed in some way? When you have a table whose purpose (and therefore content and cardinality) drifts over time , it can cause 'random performance issues' when statistics get stale.
Although I'm using Rails, this question is more about database design. I have several entities in my database, with the schema a bit like this: http://fishwebby.posterous.com/40423840
If I want to get a list of people and order it by surname, that's no problem. However, if I want to get a list of people, ordered by surname, enrolled in a particular group, I have to use an SQL statement that includes several joins across four tables, something like this:
SELECT group_enrolment.*, person.*
FROM person INNER JOIN member ON person.id = member.person_id
INNER JOIN enrolment ON member.id = enrolment.member_id
INNER JOIN group_enrolment ON enrolment.id = group_enrolment.enrolment_id
WHERE group_enrolment.id = 123
ORDER BY person.surname;
Although this works, it strikes me as a bit inefficient, and potentially as my schema grows, these queries could get more and more complicated.
Another option could be to join the person table to all the other tables in the query by including person_id in the other tables, then it would just be one single join, for example
SELECT group_enrolment.*, person.*
FROM person INNER JOIN group_enrolment ON group_enrolment.person_id
WHERE group_enrolment.id = 123
ORDER BY person.surname;
But this would mean that in my schema, the person table is joined to a lot of other tables. Aside from a complicated schema diagram, does anyone see any disadvantages to this?
I'd be very grateful for any comments on this - whether what I'm doing now (the many table join) or the second solution or another one that hasn't occurred to me is the best way to go.
Many thanks in advance
Well, joins are what databases do. Having said that, you may consider propagating natural keys in your model, which would then allow you to skip over some tables in joins. Take a look at this example.
EDIT
I'm not saying that this will match your model (problem), but just for fun try similar queries on something like this:
It seems to me that there are two scenarios in which to use JOINs:
When data would otherwise be duplicated
When data from one query would otherwise be used in another query
Are these scenarios right? Are there any other scenarios in which to use JOIN?
EDIT: I think I've miscommunicated. I understand how a JOIN works, what I'm not so sure about is when to use one.
JOINS are used to JOIN tables together with related information.
Tipical situations are where you have lets say
A user table where the user has specific security settings. The join would be used such that you can determine which settings the user has.
Users
-UserID
-UserName
UserSecurityRoles
-UserID
-SecurityRoleID
SecurityRoles
-SecurityRoleID
-SecurityRole
SELECT *
FROM Users u INNER JOIN
UserSecurityRoles usr ON u.UserID = usr.UserID INNER JOIN
SecurityRoles sr ON usr.SecurityRoleID = sr.SecurityRoleID
WHERE sr.SecurityRole = 'Admin'
LEFT joins will be used in the cases where you wish to retrieve all the data from the table in the left hand side, and only data from the right that match.
JOINS are used when you start normalizing your table structure. You can crete a table with 100s on columns, where a lot of the data could possibly be NULL, or you can normalize the tables, such that you avoid having too many columns with null values, where you group the appropriate data into table structures.
The answer to this Question has a VERY good link that has graphical display of using JOINs
JOINS are used to return data that is related in a relational database. Data can be related in 3 ways
One to Many relationship (A Person can have many Transactions)
Many to Many relationship (A Doctor can have many Patients, but a Patient can have more than one Doctor)
One to One relationship (One Person can have exactly one Passport number)
JOINS come in various flavours:
AN INNER JOIN will return data from both tables where the keys in each table match
A LEFT JOIN or RIGHT JOIN will return all the rows from one table and matching data from the other table
A CROSS JOIN will return the product of each table
You use joins when you need information from more than one table :)