Re: SQL connundrum. Can it be done?

danielroy10junk_at_hotmail.com (Daniel Roy) wrote i

> I would resolve your issue with PL/SQL if I were you. You can make it
> VERY efficient if you follow these guidelines:
<snipped>

I agree - from a techie perspectibe BULK collection and FORALL are kewl stuff and pretty fast. (been there and use that :-)

HOWEVER... the *prime* consideration is data integrity.

If you do a PL/SQL bulk process, doing let's say 10,000 rows at a time, ploughing thru a cursor containing 10 million rows..

If it fails somewhere (anywhere) along the line, is your data's integrity still intact?

And I am NOT talking from a techie viewpoint, I am talking from an end-user business perspective viewpoint.

The end-user selects a 100 rows. 10 of these have been updated by the bulk update. 90 of these were not because the bulk update failed.

Where is your data's integrity now?

How can you assure the business that their view of the data at that point in time is correct for making their business decisions and doing their business processes?

Again, don't tell me that you will add columns to cater for this and add logic into the SQL for the end-user process to get the correct/consistant/integrity view of data.. as you would be defeating the purpose of having a RDBMS in the first place, duplicating what should be done in the database itself, and leaving huge holes in your data integrity that can be defeated and _WILL_ cause your data to become meaningless and corrupt.

Is that price worth skimping on rollback segment/undo space?

--
Billy