Query values from another table based on column value

Question

I am attempting to create a query that pulls information from two other tables, however I only know which table to pull from based on a column in another table. I'm currently looking into doing this using a stored procedure (e.g. build the query and then run it) but I wanted to know if there is a better way to do this, or if I could accomplish it in a single query.

In terms of the connections, ID's are unique accross the entire database, so no two ID's will overlap. However I do not know which subtable the ID relates. I am able to find this by pulling in an unrelated table that happens to have the information (call it the Object Table). One of the columns will give me the table name for the information (in my example below, Person). I have drafted a simple example below. Can you see any way I could accomplish this in a single query? Something like this is what I am aiming for but I am starting to think its not possible.

SELECT * FROM base_table 
LEFT JOIN object ON object.id = base_table.role 
LEFT JOIN [object.type] tmp ON tmp.entity_id = base_table.entity_id

id | role | entity_id        (Base Table)
---------------------
1  | 101  | 1000


id | type                   (Objects Table)
------------
101| person

entity_id | name | etc..    (Person Table)
------------------------
1000      | Bob  | ...

I also expect unions might be a possible solution - but other then just joining all the possible tables and parsing the columns to match up properly (which it could be as many as 20 tables) I'd rather not. This solution is also a bit of a nusience since the columns don't always match in a good way (e.g. the Person table doesn't have similar columns to the Address table)

Answer 1

What you probably want to do is the following: for each possible detail-table (ie the possible values in [object.value]), write a query that only links with that one detail-table and have a WHERE clause to restrict to the proper entities. Then do a UNION ALL for all those queries.

Say you have Person, Legal Person and Counterpart as possible values in [object.type]. Suppose the detail-tables have the same names. You can write:

SELECT
  bt.*,
  dt.f1,
  -- ...,
  dt.fn
FROM
  base_table AS bt
  INNER JOIN object AS o ON o.id = bt.role
  INNER JOIN Person AS dt ON dt.entity_id = bt.entity_id
WHERE
   o.type='Person'
UNION ALL
SELECT
  bt.*,
  dt.f1,
  -- ...,
  dt.fn
FROM
  base_table AS bt
  INNER JOIN object AS o ON o.id = bt.role
  INNER JOIN [Legal Person] AS dt ON dt.entity_id = bt.entity_id
WHERE
   o.type='Legal Person'
UNION ALL
SELECT
  bt.*,
  dt.f1,
  -- ...,
  dt.fn
FROM
  base_table AS bt
  INNER JOIN object AS o ON o.id = bt.role
  INNER JOIN Counterpart AS dt ON dt.entity_id = bt.entity_id
WHERE
   o.type='Counterpart'

Answer 2

I don't think the left join idea is that bad if you just ignore object type.

Since each ID is unique you don't need to look at type at all if you use coalesce. So to use @TT model as an example:

SELECT bt.*,
  COALESCE(P.f1, L.f1, C.f1) AS f1,
  -- ...,
  COALESCE(P.fn, L.fn, C.fn) AS fn
FROM
  base_table AS bt
  LEFT JOIN Person AS P ON P.entity_id = bt.entity_id
  LEFT JOIN [Legal Person] AS L ON L.entity_id = bt.entity_id
  LEFT JOIN Counterpart AS C ON C.entity_id = bt.entity_id

Depending on your data size and indexes this might perform faster or the same as TT's example -- remember there is only 1 select with N joins while TT's has N selects, 2N joins. It really depends on your data.

If there is some field (fz) that does not show up in all types then you just don't inlcude that in the coalesce clause.

I think this style might be easier to maintain and understand and will be the same or faster as TT code.