Help with automatic insert

Question

Hello forum members!
Today I created an auxiliar table (t_final_qtd) to make a report lighter. it worked as expected but now the problem is that this table does not receive data automatically from the system.
This table receives data from 2 other tables (aevent and disposition) that receive data automatically, they're used to store event history. Each time the program inserts a new row to the event, both tables update a column called curent on the past rows changing it to 'F' and the most actual to 'T'. I want t_final_qtd to store only the rows with 'T'.
At first i thought about creating triggers but there's one problem, t_final_qtd's lighter because it only receives the most actual row of an event, it doesn't depends on "Where curent = 'T'" to retrieve data. I wanted to do with this table something like a materialized view (but not one, because the parameters are not set) that refreshes itselft, maybe a trigger or some job. Is it possible?
Thank you very much!

Answer 1

K- wrote:
BluShadow wrote:
That's not a valid test.
The first time you ran it (using the view) it had to do lots of I/O to read the data.
The second query ran quicker because the same data was already cached and didn't have to be read using expensive I/O.
The two queries are essentially the same and performance of them will be the same.
You should either do the same test, restarting the database before each query to get the same type of I/O hit, or try clearing out the cache via other means (though that's not completely accurate in itself).
The other thing you can do is to look at the explain plans and execution plans from tracing the query execution, which will show there is really no difference except for the cached data.I did the explain plans and there was really a cost difference as bellow. The view vw_final_qtd I'm using has the same structure as the table t_final_qtd.
Using vw_final_qtd: SELECT STATEMENT 83220
Using t_final_qtd: SELECT STATEMENT 1050Cost is not truly indicative of the time a query takes to execute.
The view is a stored SQL statement, so your first query...
SELECT *
FROM vw_final_qtd v --a view created exatcly as the table t_final_qtd
,ev_t e
WHERE v.dispo = e.typecode
AND v.adts BETWEEN '20101119' and '20101119235959';is essentially processed by the SQL engine as... (assuming your view is defined as "select * from t_final_qtd where current = 'T'")
SELECT *
FROM (select * from t_final_qtd where current = 'T')
,ev_t e
WHERE v.dispo = e.typecode
AND v.adts BETWEEN '20101119' and '20101119235959';... which the optimizer will look at and see that it is just the same as
SELECT *
FROM t_final_qtd t
,ev_t e
WHERE t.dispo = e.typecode
AND t.adts BETWEEN '20101119' and '20101119235959'
and t.current = 'T';... so will most likely execute it just like that, hence there is no difference between the two queries.
You can't just look at the explain plans, you need to look at the traces of the queries if you want to compare.
However, take our word for it, the two things are the same and there's no reason you can't use the view.
What would be more of a concern is the where clause:
AND t.adts BETWEEN '20101119' and '20101119235959'which is doing a range comparison on strings rather than dates or numbers. That's open to potential errors, and may be causing lack of index usage if the column is actually a data or number.