Home » SQL & PL/SQL » SQL & PL/SQL » Query history and present table (Oracle 10g)
Query history and present table [message #634938] Wed, 18 March 2015 03:49 Go to next message
sss111ind
Messages: 636
Registered: April 2012
Location: India
Senior Member

Hi All,

In emp2 there are many records (suppose 1 million records ).So we have created another table new_emp2 .
And the records created after Jan 1,2000 we have moved to new_emp2(present) before Jan 1,2000 were kept in emp2(history).
Now we have to query both the tables depending on search criteria(dates).So what is the convenient way to do that.


CREATE TABLE emp2 AS SELECT * FROM emp;
create table new_emp2 as select * from emp where 1=2;

SET DEFINE OFF;
INSERT INTO new_emp2 (EMPNO,ENAME,JOB,MGR,HIREDATE,SAL,COMM,DEPTNO) 
VALUES (7800,'SAHEED','MANAGER',7839,to_date('07-03-15 14:35:24','DD-MM-RR HH24:MI:SS'),3000,NULL,60); 
commit;

create or replace PROCEDURE get_emp_details(p_start_date    IN VARCHAR2,
                                            p_end_date      IN VARCHAR2,
                                            cur_emp_details out sys_refcursor) AS
  l_history_date number := 0;
BEGIN
  IF to_date(p_start_date, 'DD-MM-YYYY') < TO_DATE('01-01-2000') AND
     to_date(p_end_date, 'DD-MM-YYYY') < TO_DATE('01-01-2000') THEN
    OPEN cur_emp_details FOR
      SELECT ROWNUM SRNO, emp2.*
        FROM emp2
       WHERE hiredate BETWEEN p_start_date AND p_end_date; -- history 
  elsif to_date(p_start_date, 'DD-MM-YYYY') >= TO_DATE('01-01-2000') AND
        to_date(p_end_date, 'DD-MM-YYYY') >= TO_DATE('01-01-2000') THEN
    OPEN cur_emp_details FOR
      SELECT ROWNUM SRNO, new_emp2.*
        FROM new_emp2
       where hiredate between p_start_date and p_end_date; --present
  ELSE
    OPEN cur_emp_details FOR
      SELECT ROWNUM SRNO, T.*
        FROM (SELECT *
                FROM new_emp2
              union all
              SELECT * from emp2) T
       where hiredate between p_start_date and p_end_date; --present--present + history 
  END IF;
END get_emp_details;


var cur_emp_details1 refcursor;
var cur_emp_details2 refcursor;
var cur_emp_details3 refcursor;
set autoprint on;
BEGIN
get_emp_details('01-JAN-1980','10-MAR-2000',:cur_emp_details1);--HISTORY 
get_emp_details('01-JAN-2000','10-MAR-2015',:cur_emp_details2);--PRESENT
get_emp_details('01-JAN-1980','10-MAR-2015',:cur_emp_details3);--HISTORY + PRESENT
end;



Regards,
Nathan
Re: Query history and present table [message #634940 is a reply to message #634938] Wed, 18 March 2015 04:05 Go to previous messageGo to next message
John Watson
Messages: 9002
Registered: January 2010
Location: Global Village
Senior Member
I would create a view with a UNION ALL of the two tables, and query that.
Re: Query history and present table [message #634941 is a reply to message #634940] Wed, 18 March 2015 04:31 Go to previous messageGo to next message
sss111ind
Messages: 636
Registered: April 2012
Location: India
Senior Member

Thanks, I think by doing as you suggested, every time it will go for two table search instead one.
And the emp2 or new_emp2 is actually joined with other tables as well with same kind of combination.
Like (dept,new_dept,salgrade,new_salgrade)
Re: Query history and present table [message #634942 is a reply to message #634941] Wed, 18 March 2015 04:35 Go to previous messageGo to next message
John Watson
Messages: 9002
Registered: January 2010
Location: Global Village
Senior Member
No. You need to create your tables with appropriate constraints and indexes, so that the optimizer knows what rows can and cannot be in each table. This is what is known as a PARTITIONED VIEW, and can be fully optimized if enabled appropriately. Read up on the concept, and on the _partition_view_enabled parameter.
Re: Query history and present table [message #634946 is a reply to message #634942] Wed, 18 March 2015 05:00 Go to previous messageGo to next message
sss111ind
Messages: 636
Registered: April 2012
Location: India
Senior Member

Thank John, pointing out this feature,but in another thread I found something like

"My concern with the "partitioned view" is that it might go away in the near future,
development on it stopped in about 1995, and partitioning is our future direction."

https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:5955697076876

[Updated on: Wed, 18 March 2015 05:00]

Report message to a moderator

Re: Query history and present table [message #634947 is a reply to message #634946] Wed, 18 March 2015 05:07 Go to previous messageGo to next message
John Watson
Messages: 9002
Registered: January 2010
Location: Global Village
Senior Member
That article is attempting to persuade you to buy Enterprise Edition plus the Partitioning Option. For most of humanity, who use Standard Edition, partitioned views are the only way to do this. They are not going to go away. If you can throw money at the problem, then you have a different solution.
Re: Query history and present table [message #634948 is a reply to message #634947] Wed, 18 March 2015 05:18 Go to previous messageGo to next message
sss111ind
Messages: 636
Registered: April 2012
Location: India
Senior Member

If we are using Enterprise Edition currently then whether the partitioning table is more useful than partition view.

[Updated on: Wed, 18 March 2015 05:49]

Report message to a moderator

Re: Query history and present table [message #634963 is a reply to message #634948] Wed, 18 March 2015 07:41 Go to previous messageGo to next message
Solomon Yakobson
Messages: 3310
Registered: January 2010
Location: Connecticut, USA
Senior Member
sss111ind wrote on Wed, 18 March 2015 06:18
If we are using Enterprise Edition currently then whether the partitioning table is more useful than partition view.


Enterprise Edition != Partitioning option.

Partitioning Option requires additional license on top of Enterprise Edition.

SY.
Re: Query history and present table [message #634967 is a reply to message #634963] Wed, 18 March 2015 07:59 Go to previous message
sss111ind
Messages: 636
Registered: April 2012
Location: India
Senior Member

Thanks SY,

Suppose all options(advantages) are available.In this regards what is the better option whether to go for
1.union all
2.or if else in the coding
3.or Partitioning
4.or any other

[Updated on: Wed, 18 March 2015 08:02]

Report message to a moderator

Previous Topic: Use ALter table in PL/SQL block
Next Topic: Cumulative agreegating strings
Goto Forum:
  


Current Time: Tue May 26 19:10:14 CDT 2026