Detail rows for accounts that occur three times

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT SQL How to check SQL query construction with the Mimer Validator Using the SQL GROUP BY clause for counting combinations How to use an SQL CASE expression How to sort an SQL UNION query with special ORDER BY sequence How to use string functions to make an SQL join An SQL solution for a customer order homework problem How to use SQL's POSITION function with substrings Using SQL date functions to get totals for last three days Using CASE in the SQL ORDER BY clause What's the difference between an SQL inner join and equijoin? Oracle and SQL Using the SQL GROUP BY clause for counting combinations How to use an SQL CASE expression How to use the Oracle Database SQL Reference Manual How to use SQL Developer to run SQL statements How to work with the Oracle database home page How to use SQL*Plus in Oracle How to use SQL Developer to work with an Oracle database How to view and edit table column definitions How to sort an SQL UNION query with special ORDER BY sequence How to use string functions to make an SQL join Oracle and SQL Research

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary autonomous transaction  (SearchOracle.com) CFML  (SearchOracle.com) dynamic SQL  (SearchOracle.com) foreign key  (SearchOracle.com) Java Database Connectivity  (SearchOracle.com) Open Database Connectivity  (SearchOracle.com) Oracle  (SearchOracle.com) stored procedure  (SearchOracle.com) The Open Group  (SearchOracle.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

The difficulty with this type of problem is that it requires returning detail rows for a situation which is easily solved with HAVING. However, to use HAVING we have to use GROUP BY, and then the detail rows are aggregated. The way to approach this problem is to break it down into components. The first component of the solution does involve the HAVING clause.

select Acct 
  from Weekly
group
    by Acct
having count(*) >= 3

Note that COUNT(DISTINCT WeekEnding) also works. Whether we use this or the simpler COUNT(*) depends on whether the combination of WeekEnding and Acct is unique. Counting distinct values may be necessary if, for example, there are other columns you didn't mention, such as customer. In that case, we might have one row per customer per account per week ending date, so COUNT(DISTINCT WeekEnding) is necessary if the GROUP BY is only on the account.

Now that we know which accounts qualify, we can build the other component, which is the selection of all detail rows for the accounts which qualify. This can be accomplished in two ways. The first method uses an IN subquery:

select WeekEnding
     , Amt
     , Acct 
  from Weekly
 where Acct in
       ( select Acct 
           from Weekly
         group
             by Acct
         having count(*) >= 3 )

The second method uses the same subquery but as a derived table in the FROM clause:

select WeekEnding
     , Amt
     , Acct 
  from Weekly
inner
  join ( select Acct 
           from Weekly
         group
             by Acct
         having count(*) >= 3 ) as ok_accts
    on ok_accts.Acct = Weekly.Acct

What is the difference between these two solutions? As far as execution goes, they should perform the same. But the derived table has an advantage. Suppose that if, instead of one column, the HAVING condition needed to be based on a GROUP BY involving two columns. What if you wanted details for all customer accounts that occurred at least 3 times?

The first solution would be:

select WeekEnding
     , Amt
     , Acct 
     , Customer
  from Weekly
 where ( Acct, Customer ) in
       ( select Acct 
              , Customer
           from Weekly
         group
             by Acct
              , Customer
         having count(*) >= 3 )

This solution now uses what is called a row constructor, and this is perfectly valid SQL. The problem with row constructors is that not every database engine supports them. Yet.

Now imagine what the query involving the join to the derived table would look like.