How to change table but don't touch SQL using it?

Question

we have old_table (date, key, value1, value2, value3)
where we have values on every key for every day
values are changed very rarely, so we are considering to redesign table to slow changing dimension:
new_table (date_start, date_end, key, value1, value2, value3)
where new record with new date_start + date_end + key entry is added only when values are changed
BUT all SQL which used to query old_table:
SELECT ...
from old_table
where date = date '2010-01-01'
- will not work anymore!
We know one straightforward approach - VIEW based multiplication of rows - which will help to use old SQL:
create table table_new(date_start date, date_end date, key number, value1 number, value2 number, value3 number)
Table created
insert into table_new values(date'2010-01-01',date'2010-01-05',1,1,2,3);
1 row inserted
insert into table_new values(date'2010-01-06',date'2010-01-15',1,11,22,33);
1 row inserted
create or replace view old_table as
select trunc(date_start)+rn as date_, key, value1, value2, value3
from table_new tn
, (select rownum-1 rn from all_tables where rownum < 100) p
where p.rn <= trunc(date_end-date_start)
View created
SELECT *
from old_table
where date_ = date '2010-01-01';
DATE_ KEY VALUE1 VALUE2 VALUE3
01/01/2010 1 1 2 3
SELECT *
from old_table
where date_ = date '2010-01-10';
DATE_ KEY VALUE1 VALUE2 VALUE3
10/01/2010 1 11 22 33
But we dont believe than it is efficient on rowcount about a million.
Is there any approach?
ref cursor, pipelined, something else?
the only one requirement is - OLD SQL with "where date = date '2010-01-01'" should work unchanged.

Answer 1

I don't think that helps because it isn't just that there is a different table, but the queries are different. In hindsight, the way to avoid this problem rather than "fix" it is to isolate your queries into packages and then the application is calling the modified (or overloaded?) function or procedure and the impact is minimized.
If the OP is trying to minimize storage by saving only ranges instead of the data for each and every day, then one solution would be to make the new view generate the values for each day within the range on the fly. (There was a similar question in this forum just this week about generating missing data.) The queries think they are going after the original table because there is in fact a row in the view for each day. But that would (possibly) make sense only if it was storage that was being minimized. I don't think this approach would be as efficient as using the actual date ranges if the data is migrated to such a table. I wasn't clear from the OP what the goal was behind the table change.