Message from discussion
SECUREFILES disaster
Received: by 10.68.236.170 with SMTP id uv10mr1332860pbc.4.1335269586607;
Tue, 24 Apr 2012 05:13:06 -0700 (PDT)
Path: r9ni92964pbh.0!nntp.google.com!news1.google.com!news.glorb.com!feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Noons <wizofo...@yahoo.com.au>
Newsgroups: comp.databases.oracle.server
Subject: Re: SECUREFILES disaster
Date: Tue, 24 Apr 2012 22:13:04 +1000
Organization: Noons Inc
Lines: 18
Message-ID: <jn65ch$3qa$1@dont-email.me>
References: <pan.2012.04.22.19.20.39@gmail.com> <pan.2012.04.22.19.24.26@gmail.com> <6124715.1626.1335188000775.JavaMail.geo-discussion-forums@ynee1>
Reply-To: wizofo...@yahoo.com.au
Mime-Version: 1.0
Injection-Date: Tue, 24 Apr 2012 12:13:06 +0000 (UTC)
Injection-Info: mx04.eternal-september.org; posting-host="e7vFrlcl3j5lka5MTqwzFg";
logging-data="3914"; mail-complaints-to="ab...@eternal-september.org"; posting-account="U2FsdGVkX19FVZAbK4bbswFeG9ircLuS"
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
In-Reply-To: <6124715.1626.1335188000775.JavaMail.geo-discussion-forums@ynee1>
Cancel-Lock: sha1:KuJhD+hwayUPPdwphlemYKxNOWQ=
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mark D Powell wrote,on my timestamp of 23/04/2012 11:33 PM:
> The LOB data type has never been known for its space efficiency.
Aye! Indeed!...
> of separate LOB columns each holding a portion of the existing
> data that serves aspecific purpose or involve some form of
> versioning so that multiple rowsexist where new versions of
> the data result in new rows in the table.
> Potentially old versions or old enough versions could be purged
> freeingentire LOB's allowing better reuse of LOB space.
I share this experience as well. A while ago I was
involved in a db design that required updates to a LOB.
We ended up simply inserting a new version and deleting the
old one: it was much faster than waiting for Oracle's
"efficient" handling of LOB updates...