Re: Avoiding generating redo logs

In article <1158411086.860994_at_bubbleator.drizzle.com>, DA Morgan says...
>
> I am in full agreement with Sybrand and others here. Your business case
> around not generating redo starts with "I want" and that is not a
> business case.

That is not the business case at all - the business case is to provide a flexible user interface to the users of a system via a web browser. The question of redo is simply something that occurred to me that perhaps, in the case where the need to recover data from a particular table in the event of some kind of failure did not exist, might be able/recommended to suppress.
>
> My recommendation would be that you use global temporary tables to cache
> the data as in the following:
>
> CREATE GLOBAL TEMPORARY TABLE test (
> zip_code VARCHAR2(5),
> by_user VARCHAR2(30),
> entry_date DATE)
> ON COMMIT PRESERVE ROWS;
>
> This is likely the most efficient structure for your purposes.

Not when using apache/mod_plsql - a new session is started on every interaction.

>
> But I am left wondering why you think it desirable to let an end user
> sort and filter anything. Wouldn't it be far easier to just teach them
> how to use the WHERE and ORDER BY clauses correctly?
>

Have you ever used a browser-based system where you the user clicks a column heading to re-order the resukts into price or date order? You're right, of course, let's teach the end users about WHERE and ORDER BY and give them a little field into which they can type their own SQL statements which we execute dynamically. Brilliant.

-- 

jeremy