Hey folks,

I have a variable number of identically structured & similarly named
tables for which I would like to expeditiously execute a UNION ALL in
succession. e.g. "SELECT * from (x-2) UNION ALL SELECT * FROM (x-1) UNION
ALL SELECT * FROM x UNION ALL" etc... where (x-2), (x-1), x are three such
tables. I can pull all the tables I need to create this very large UNION ALL
query from INFORMATION_SCHEMA.TABLES, so is there any way to somehow
construct a looped stored procedure such that I don't have to manually type
in the full UNION ALL query?

Thanks,

Dave
--
______________________________
Remove "_SPAM" to reply directly.

David Shorthouse wrote:
Why?

Create a UNION by querying the INFORMATION_SCHEMA and then cut and
paste the result. Put the UNION in a view and query that in your proc.
Take a look at the partitioned views topic in Books Online.

Better still, consider combining this into a single table unless it's a
case of "I'm not allowed to fix my database".


--
David Portas, SQL Server MVP

Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.

SQL Server Books Online:
http://msdn2.microsoft.com/library/m...S,SQL.90).aspx
--

I'll take it as read that performance is not a problem here as if it were
the driving factor a DB redesign would not be out of the question.

Insead of trying to perform a union all, maybe a different appear would be
better....

1. Create a temporary table with the structure of your output.
2. create a cursor which will loop through the tablenames that you need to
query.
3. use the table name to create a dynamic sql statement (see sp_executesql)
that will populate the temporary table with the data that you need to
select.
4. after the loop, perform a single select on the temp table.

Be warned, the performance of this will be extremely bad.


--
Regards

Colin Dawson
www.cjdawson.com


"David Shorthouse" <davidshorthouse (AT) shaw_SPAM (DOT) ca> wrote

This is simply the way the db has been designed. Individual clients access
individual tables.

This is what I am attempting to do; scheduling a table creation by creating
a UNION ALL of these individual tables. Rather than having to manually add
these tables to the UNION ALL query prior to the creation of the one large
result, I am attempting to programmatically create this UNION ALL because
there are a variable number of individual tables. So, I'm not sure how the
idea you have above will accomplish this.

Dave

Colin,

Thanks for the ideas. Performance is not an issue here because I am indeed
creating a table from this large UNION ALL query result.

Well, kill the moron who did this and fix it!! The name of this design
flaw is "attribute splitting" and it can take several forms.

1) Putting the same set of entities into many tables. There are two
sub-cases.

a.The absolute newbie usually mimics sequential numbered or
temporally labeled tapes in each table.

b. The newbie with a few weeks experience splits the table on the
values of one or more attributes. For example, taking a Personnel
table and making it into "MalePersonnel" and "FemalePersonnel" tables.

2) Taking a single attribute and splitting in into multiple columns.
There are two sub-cases.

a. The multiple columns are in the same table. The most common
example is having a group of bit flag columns instead of a single
well-design encoding in a column. They have to be combined to get the
attribute's value and you need multi-column CHECK() constraints to
control the combinations.

b. The split column is in multiple tables. The most common example
is trying to force an OO design in an RDBMS, so that joins are required
to assemble a meaningful entity. . They have to be combined via a join
to get the attribute's value.

As David has suggested, look at partitioned views. You can create a
single entity (a view) that contains all of the data from your tables.
Through the use of check constraints, the optimizer can do partition
exclusion, which means it will only select data from the appropriate
underlying tables. The VIEW is also able to be UPDATED, so you end up
dealing with a lot less mess than trying to dynamically select the
appropriate tables during your selection time.

Of course, the only real reason for using a partioned view is to help
performance when dealing with large datasets; in your case, it sounds
like you're having to do an end-run around a design choice that should
be reconsidered.

Stu