[Tfug] RDBMS reprise

[Tim Ottinger]

Bexley Hall wrote:
> *You* (I, the programmer) know this is what happened.
> But, Joe User doesn't understand this.  Instead, you
> get a call to tech support (angry/confused customer)
> and you have to explain what *might* have happened.
>   
Weinberg says: A problem is a difference between things
as perceived and things as desired. 

It doesn't have to be confusing.  What if the user
can see that the name was updated while you were
looking the phone number?  Is it still a problem?
> [note the PDA example falls down here as it is too
> simplistic.  Imagine looking looking at a directory's
> contents, selecting a file and then being told that
> the file doesn't exist!  "Huh?  I just *saw* it?!!!"
> Sure, even if you refresh the directory listing and
> show the user that it is no longer present, it
> results in confusion on his part:  "Where did it go?
> Why??"]
>   
Doesn't the user know that the content can change?
Why does he think it cannot? 

What if the file link can give a 404? Users are used to
invalid links.  They  know  links can stale or pages (even
sites) can be unavailable.  It's astonishing only if you
expect otherwise. 

When buying air travel, you see seat 6A is empty, but when you try
to get it, you find it's no longer available. Are you astonished?
What if the onscreen representation of the seat changed colors
(grayed out) when the other passenger confirmed it? Would you
think it was a slick realtime system, or a seriously broken program?

Alternatively, when someone else is looking at *maybe* reserving a
seat the server locked it then locks could be held for minutes or hours.
It simply would not work for online air travel retailers, nor for the
airlines themselves.  What if they reserve a block of 5 seats, only to
find out after committing their money that two of them were really
taken an hour ago?

Seat reservation data has to be live, and live things change. In many 
cases,
if you prevent changes, then you are also preventing *work*. I don't know
what your system does, what it calls "work".  That's the balancing
concern.

Consider distributed version control systems. You work with copies,
but you find out that changes have occurred, and deal with those
before pushing your changes out to the world.

I don't know any RDBMS that will give you change metadata.  Yes, it's
more complicated.
> That was my point.  Taking bite sized pieces
> complicates the recovery logic, forces it to vary
> as a function of the data/application *and* confuses
> the end user.  In light of that, it seems that
> server-side caching is the better approach.  It
> also gives a simple upgrade path -- add more memory
> to the server and *all* clients benefit.
>   
I'm not sure it solves all your problems. It probably
depends on how live your data is, and how long it
can live in denial. :-p

Of course, there are myriad ways to fail.  Nothing will
ever be done if all possible objections must first be
overcome.

Just try it a few different ways.  See how it works out.
Sometimes the problems we foresee are illusory, and
the ones we don't see have teeth.

I'm not saying you're not right.  I'm suspecting that
you don't know from actual experiment that you're
right.  I also suspect that you not be quite as right
as you assume, but I don't know what you're actually
doing.l

> But the data makes sense to the user.  If John Doe's
> address has changed in the intervening
> seconds/minutes/hours/days since he saw the list
> of names, at least the data that he had represents
> a valid data point that *did* exist (at one time).
> Contrast that with having a name that *existed*
> but the record behind it that *doesn't* (any more)
>   
The trick is knowing what change you can
ignore, what you can tolerate, what you
can detect, etc.  An RDBMS isn't built to do that
for you.
> <grin>  I suspect its just one of those problems
> that *has* no real (clean) solution.  Can't squeeze
> both ends of the balloon at the same time!
>   
Right, you can't have updates to data and have it static at the same time.
It's not a computer problem.  It's a real world thing.

So you find ways to balance it.

Tim