Simple Example: Lets say you have a Students table, and a Lockers table.
Each student can be assigned to a locker, so there is a "Locker Number" column in the student table. More than one student could potentially be in a single locker, but especially at the beginning of the school year, you may have some incoming students without lockers and some lockers that have no students assigned.
For the sake of this example, lets say you have 100 students, 70 of which have lockers. You have a total of 50 lockers, 40 of which have at least 1 student and 10 lockers have no student.
INNER JOIN is equivalent to "show me all students with lockers".
Any students without lockers, or any lockers without students are missing. Returns 70 rows
LEFT OUTER JOIN would be "show me all students, with their corresponding locker if they have one".
This might be a general student list, or could be used to identify students with no locker. Returns 100 rows
RIGHT OUTER JOIN would be "show me all lockers, and the students assigned to them if there are any".
This could be used to identify lockers that have no students assigned, or lockers that have too many students. Returns 80 rows (list of 70 students in the 40 lockers, plus the 10 lockers with no student)
FULL OUTER JOIN would be silly and probably not much use.
Something like "show me all students and all lockers, and match them up where you can" Returns 110 rows (all 100 students, including those without lockers. Plus the 10 lockers with no student)
CROSS JOIN is also fairly silly in this scenario.
It doesn't use the linked "locker number" field in the students table, so you basically end up with a big giant list of every possible student-to-locker pairing, whether or not it actually exists. Returns 5000 rows (100 students x 50 lockers). Could be useful (with filtering) as a starting point to match up the new students with the empty lockers.
Original here
|
General The code works The code is easy to understand Follows coding conventions Names are simple and if possible short Names are spelt correctly Names contain units where applicable There are no usages of magic numbers No hard coded constants that could possibly change in the future All variables are in the smallest scope possible There is no commented out code There is no dead code (inaccessible at Runtime) No code that can be replaced with library functions Variables are not accidentally used with null values Variables are immutable where possible Code is not repeated or duplicated There is an else block for every if clause even if it is empty No complex/long boolean expressions No negatively named boolean variables No empty blocks of code Ideal data structures are used Constructors do not accept null/none values Catch clause...
Comments
Post a Comment
Want to tell something about this post. Please feel free to write...