Question

Using Microsoft SQL 2000, I will like to join multiples tables (A, B, C, and D) together. I know table A always exists. However, I only know at least one of the table form (B, C, D) exists.

Is there any way I could do something like this to accomplish what I am trying to do?

Select * form table a     
If table b exists left Join table b on a.id = b.id    
If table c exists left Join table c on a.id = c.id    
If table d exists left Join table d on a.id = d.id

Answer 1

You’ll have to check the data dictionary views for that and use dynamic SQL

declare @myquery varchar(1000)

set @myquery = 'Select * from a '
if exists (select * from sysobjects where xtype='U' and name = 'b')
begin
   set @myquery = @myquery + 'inner join b on b.id = a.id '
end
if exists (select * from sysobjects where xtype='U' and name = 'c')
begin
   set @myquery = @myquery + 'inner join c on c.id = a.id '
end
if exists (select * from sysobjects where xtype='U' and name = 'd')
begin
   set @myquery = @myquery + 'inner join d on d.id = a.id '
end

exec( @myquery)

I’ve used sysobjects, however you are encouraged to use Information Schema Views instead

And, a BIG DISCLAINER ON DYNAMIC SQL

Advantages

• It gives flexibility and scalability
• It can reduce the number of lines of code written

Disadvantages

• It can become very complex and difficult to read. Think about quotes embedded in quotes, and other such things.
• It can have a detrimental effect on code stability. Some Dynamic SQL errors will not be known until run time. (An example of this is where you reference a non-existent table)
• Dynamic SQL code is harder to test than the equivalent static SQL. It may also be impossible to test for every possible circumstance that your Dynamic SQL will encounter, thus introducing inherent risk.
• It will be more difficult to conduct an effective impact analysis on Dynamic SQL in your code-base.
• SQL injection and misuse – Dynamic SQL is more prone to misuse, and is invariably less safe than static SQL
• The queries code within Dynamic SQL is not subject to a query plan, and as such optimisations may be missed. As such, it can be slower than the equivalent static SQL
• As the SQL query is not known until runtime, it can be harder to performance-tune SQL Dynamic code (for example, determining the indexes that might be required on a table)