Re: Union quries: INTERSECT, MINUS, etc

Jonathan,

I can't think of any specific examples but the four operators all have their place:

UNION - A quick way to merge result sets. If, for example, you have actual financial data in one table and budget financial data in another table and need to spool all data to a file then UNION is an easy way to merge the two tables into a single cursor. I guess a natural alternative would be a view - but this then breaks the statement up into two statements SELECT (with selection criteria) and VIEW (which will effectively hide the underlying tables from the main query) - making maintenance worse but could be useful if the tables are joined often.

UNION ALL - More significant when you may be deliberately creating duplicate records and need to show both records or when you know that no duplicates will be created and can therefore save on a sort operation. My first example would be better implemented as union all since "actual" and "budget" being extracted as constants from each table ensures no overlap.

INTERSECT - Can often be used in the same scenario's as "WHERE EXISTS" or "IN" but may allow more complex conditions to be compared.

MINUS - Can often be used to implement complex "WHERE NOT EXISTS" or "NOT IN". For example, a "student" table may hold "number_of_enrolled_subjects" and a "studentsubject" table may map students to subjects... If you need to return the students which have this attribute set incorrectly (ie: corrupt data) then a simple MINUS query can compare the attribute to the COUNT(*) from "studentsubject".

I think the important thing to remember is that all of these operations can normally be accomplished using different SQL syntax. The decision comes down to a couple of factors:

1. Maintenance - some ways of writing a query may represent the underlying logic much easier. MINUS, for example, can break a complex statement down into two simpler queries which may make their purpose easier to understand. UNION may negate the need for a view - which can be a good or bad thing depending on other factors.
2. Execution approach. Often the above operators are resolved using a sort - the volume of records in each side of the query and configuration of your database may make this desirable, or it may not. "WHERE EXISTS", on the other hand will normally be resolved using nested loops or hash joins. With small recordsets (not necessarily the final resultset since two of these operators are effectively data filters) the approach probably doesn't matter, but as data volumes and performance demands increase the decision can be significant.

Hopefully this has added some food for thought.

                                                                                                                                      
                      Jonathan Gennick                                                                                                
                      <jonathan_at_gennick        To:       Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>                  
                      .com>                    cc:                                                                                    
                      Sent by:                 Subject:  Union  quries: INTERSECT, MINUS, etc                                         
                      ml-errors_at_fatcity                                                                                               
                      .com                                                                                                            
                                                                                                                                      
                                                                                                                                      
                      24/07/2003 23:04                                                                                                
                      Please respond to                                                                                               
                      ORACLE-L                                                                                                        
                                                                                                                                      
                                                                                                                                      

I'm doing research for an article on union queries. I'm interested in finding examples of problems that were solved using UNION, UNION ALL, INTERSECT, or MINUS, with the latter two being of special interest because I don't see them used very often. If you can think of an interesting problem you've solved using one of these keywords, I'd love to hear about it.

Best regards,

Jonathan Gennick --- Brighten the corner where you are http://Gennick.com * 906.387.1698 * mailto:jonathan@gennick.com

Join the Oracle-article list and receive one article on Oracle technologies per month by email. To join, visit
http://four.pairlist.net/mailman/listinfo/oracle-article, or send email to Oracle-article-request_at_gennick.com and include the word "subscribe" in either the subject or body.

--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Jonathan Gennick
  INET: jonathan_at_gennick.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).





<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

   Privileged/Confidential information may be contained in this message.
          If you are not the addressee indicated in this message
       (or responsible for delivery of the message to such person),
            you may not copy or deliver this message to anyone.
In such case, you should destroy this message and kindly notify the sender
           by reply e-mail or by telephone on (61 3) 9612-6999.
   Please advise immediately if you or your employer does not consent to
                Internet e-mail for messages of this kind.
        Opinions, conclusions and other information in this message
              that do not relate to the official business of
                         Transurban City Link Ltd
         shall be understood as neither given nor endorsed by it.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>




<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Privileged/Confidential information may be contained in this message.
If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone.
In such a case, you should destroy this message and kindly notify the sender by reply e-mail or by telephone on (03) 9612-6999 or (61) 3 9612-6999.
Please advise immediately if you or your employer does not consent to Internet e-mail for messages of this kind.
Opinions, conclusions and other information in this message that do not relate to the official business of Transurban Infrastructure Developments Limited and CityLink Melbourne Limited shall be understood as neither given nor endorsed by them.