On Mon, Apr 25, 2011 at 2:03 PM, Jesper Krogh <jesper@krogh.cc> wrote:
> On 2011-04-25 20:00, Leonardo Francalanci wrote:
>>> The amount of data loss on a big table will be <1% of the data
>>> loss caused by truncating the whole table.
>>
>> If that 1% is random (not time/transaction related), usually you'd
>> rather have an empty table. In other words: is a table that is not
>> consistant with anything else in the db useful?
>>
> Depends on the application, if it serves for pure caching then it is fully
> acceptable and way
> better than dropping everything.
Whoah...
When cacheing, the application already needs to be able to cope with
the case where there's nothing in the cache.
This means that if the cache gets truncated, it's reasonable to expect
that the application won't get deranged - it already needs to cope
with the case where data's not there and needs to get constructed.
In contrast, if *wrong* data is in the cache, that could very well
lead to wrong behavior on the part of the application.
And there may not be any mechanism aside from cache truncation that
will rectify that.
It seems to me that it's a lot riskier to try to preserve contents of
such tables than it is to truncate them.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"