tags:

views:

71

answers:

3

I have 5 Tables in MS Access as

Logs [Title, ID, Date, Author]
Tape [Title, ID, Date, Author]
Maps [Title, ID, Date, Author]
VCDs [Title, ID, Date, Author]
Book [Title, ID, Date, Author]

I tried my level best through this code

SELECT Logs.[Author], Tape.[Author], Maps.[Author], VCDs.[Author], Book.[Author]
FROM Logs
   , Tape
   , Maps
   , VCDs, Book
WHERE ((([Author] & " " & [Author] & " " & [Author] & " " & [Author]& " " & [Author])        
Like "*" & [Type the Title or Any Part of the Title and Press Ok] & "*"));

I want to select all of these fields in a single query. Suppose there is Adam as author of works in all tables. So when i put Adam in search box it should result from all tables.

I know this can be done by having single table or renaming fields names but that's not required.

Please help.

+2  A: 

Try creating a new query that UNIONS all the tables and then change your existing query to select from that rather than each underlying table independently. So something like:

SELECT * 
  FROM NewUnionQuery 
 WHERE NewUnionQuery.Title LIKE "*" & [Enter a Title] & "*";

Also, get a good book on SQL and read it.

Trevor Tippins
+1 for the book tip (besides sound advise on using the union query!)
lexu
+4  A: 

You could try this:

   select 'Logs', Title, ID, Date, Author from Logs where Author like 'Adam'
union
   select 'Tape' ,Title, ID, Date, Author from Tape where Author like 'Adam'
union
   select 'Maps',Title, ID, Date, Author from Maps where Author like 'Adam'
union
   select 'VCDs', Title, ID, Date, Author from VCDs where Author like 'Adam'
union
   select 'Book', Title, ID, Date, Author from Book where Author like 'Adam'

or better even you could create a view to 'union' the tables and then select from the view.

lexu
+5  A: 

I second what lexu and Trevor Tippins suggest and these will solve your immediate problem.

Still, please re-examine your attitude towards redesigning the tables. The use of UNION queries as a core part of application is an indicator of problems in the database design.

If your application often works with all five tables then I would say that the database model should show that. Also, the performance of UNION queries is not stellar, especially in MS Access and you'll get other penalties such as non-updateable result set.

If you had another table called Media which would hold all the common fields from the five tables plus the media type you could still have tables for each of the particular media which would have specific fields and would refer to the main Media table through IDs.

Be sure to understand all concepts mentioned, for example here, before your databases and applications get too complex because redesign is going to impact all the queries, forms and code, and later it happens the more work it will require.

Unreason
The performance penalty is there only with plain UNION which removes duplicates. If the records come from different tables, and each table is a different entity, and there are no duplicate records in the tables, there should be no need to remove duplicates, so you can use UNION ALL, which is quite fast (since it skips that step). You may need an explicit ORDER BY in that case, though (not sure on that -- you'd have to check the results).
David-W-Fenton
Let me emphasize the point that you have a schema error, which is indicated by the fact that you have the same attributes in multiple tables. The tables may have some variation in attributes, but the fact that you need to UNION them all is an indication that they ought to be in a single table, with a field indicating the type of item represented by each record.
David-W-Fenton
@David, comment 1: Performance penalty will come always, several reasons a) RDBS can not know if there are no duplicates - it has to check, only with single table it can be skipped b) using indexes from five tables is worse then using index from a single table@David comment 2 - Re schema, my point exactly. :)
Unreason
If you use UNION ALL, it doesn't de-dupe, i.e., it's like the difference between SELECT * and SELECT DISTINCT * -- the latter takes longer because it has to eliminate the duplicates (whether or not there are indexes available to do that). This is not to say it would be as fast as querying the same data from a single table, but it's not going to be a significant performance issue in comparison to UNION alone.
David-W-Fenton
Fair point about UNION ALL, I've run some tests:Open recordset, movefirst, while not .EOF movenext, 100k records in each table, 500k in normalized table: for UNION it took 45s, for UNION ALL it took 13s, for recordset on normalized table it took ~1s.For query benchmark I did 'SELECT COUNT(*) FROM (<sql>) WHERE Date between some dates': for UNION it did 49s, for UNION ALL 3s and for normalized table 0s (Date indexed in both normalized table and in union tables).
Unreason
So it would seem that UNION ALL does not hurt performance that much, BUT as soon as I introduced sort (on an indexed column Date) things went bad - UNION does it in 57s, UNION ALL takes 26s and normalized table is at 1s.
Unreason
Sorry, but did you write what you meant? According to what you wrote, UNION ALL is still faster with an ORDER BY. The point is: use UNION or UNION ALL according to what's appropriate. If there are no duplicates to be removed from the result set, then use UNION ALL.
David-W-Fenton
Yes, I agree. I was just emphasizing and investigating the performance penalty of UNION and UNION ALL over normalized table. UNION ALL does not hurt as much as UNION, but it is slower anywhere from 3x (for simple counts) to 30x (for simple but sorted resultsets).
Unreason