Joining tables without keys causes incorrect results - sql

Question

I have 2 tables - one master and the other lookup. both don't have any keys. The structure of the tables is below.
first name last name role location Compensation Level state
john smith Manager LA A CA
john smith Manager BOS B MA
super smither developer LA B CA
tina taylor supervisor SFO A CA
tina taylor supervisor BOS B MA
first name last name role dept
john smith manager finance
john smith manager hr
super smither developer PA
tina taylor supervisor HR
tina taylor supervisor hr
very understandably, joining the two tables to get the dept for a first name, last name and role combination will result in incorrect results since there are other fields involved in the mix which identify a true unique record.
But given a structure like this, is there any way i can join the two tables to get the dept?
Using an inline subquery is not an option due to the way the final procedure is designed and due to other factors.
Any thoughts on this?
Expected output:
first name last name role location Compensation state dept
john smith Manager LA A CA finance
john smith Manager BOS B MA hr
super smither developer LA B CA PA
tina taylor supervisor SFO A CA HR
tina taylor supervisor BOS B MA HR

Answer 1

Here's an example that gives deterministic results, but they're arbitrary results. It's simply bases on determining an "ordered position" in each table, so that a choice can be made, and that choice be the same every time the query is executed, but there is no way to know that the choice is the correct one.
WITH
sorted_t1 AS
(
SELECT
*,
ROW_NUMBER() OVER (PARTITION BY first_name, last_name, role
ORDER BY compensation_level, location, state) AS discriminator
FROM
t1
)
,
sorted_t2 AS
(
SELECT
*,
ROW_NUMBER() OVER (PARTITION BY first_name, last_name, role
ORDER BY dept) AS discriminator
FROM
t2
)
SELECT
*
FROM
sorted_t1 t1
FULL OUTER JOIN
sorted_t2 t2
ON t1.first_name = t2.first_name
AND t1.last_name = t2.last_name
AND t1.role = t2.role
AND t1.discriminator = t2.discriminator
NOTES:
This assumes a "case-insensitive" collation sequence. Otherwise the john smith rows will never join (as 'Manager' wouldn't match 'manager')
Similarly, the two tina taylor rows in table 2 are different ('hr' vs 'HR'), but if the collation sequence is case-insensitive it doesn't matter which gets joined to which, as there is no "material" difference between the rows.
It's also worth noting that in the example above there is no Real Reason to assume that the 'John Smith' from LA is in finance. The query simply forces that association because or the ORDER BY chosen in the ROW_NUMBER(). This means that when using this technique you really should be using other fields, one's that mean something in relation to each other.