[Tfug] RDBMS reprise

[Tim Ottinger]

Bexley Hall wrote:
> Hi, Tim,
>
> I don't see any way to *avoid* making two (or more)
> passes at the server to get all the data that an
> application may need (e.g., the PDA example I
> sited is a great model for thinking about the
> sorts of issues that can arise... "How large of
> an address book do you expect the user to have?
> How many fields in each 'contact'?"  etc.)
>   
Okay.  Have you worked on making more, narrower queries?
for instance, if you want the address book, you probably don't
really want the address book. You might want record ID and
name first, which is less bandwidth and local storage.  Maybe
you also only want As and Bs for the first screen.  When
someone selects a person by name, then you might want the
one person's record.  

Did you already do that?   The initial question sounded like
you wanted too much at once.

BTW:  Selecting by first letter of name is generally much
cheaper than setting the 'first' and 'length' on a bigger
query.  Especially if the db is indexed apropriately.
> Currently, I qualify each successive query with
> those from which it was (obviously) derived so
> that I can tell if a record has "disappeared",
> etc.  I can see no way around this possibility
> short of explicit locking *or* implicit locking
> (even client-side locking!)
>   
Probably okay to be optimistic, then. I get  (id,name)
as (1234, "Ottinger, Tim") then when I select my name,
I select from people where id = 1234.  If there is no
such record, then I know that something happened
on the other end.

If you can't save data, and can't hold locks, then you'll
have to have some recovery logic.  Tradeoffs, y'know?

> Datasets vary.  Some may be wide, others narrow.
> E.g., consider the smarts that you might add to
> fetch the area code for a particular address
> based on its ZIP code (I, for one, don't enter
> area codes in my address book so if I ever
> forgot Tucson's -- for example -- I would have
> to make this extra step manually).
>   
Yeah, but you can always get the very least you need,
and not select any data that you *might* need later.
So you get the fewest columns of the fewest rows you
can possibly get away with.  I don't know any better
way to deal with having a lack of space on the client.

Well, there is the idea of pulling in data and compressing
it one way or another.  Then you get a little storage back
for a bit of processing.  But that's hardly a panacea either.
More data on the client == more stale data on client. 

If you're low on resources, you have to be high on finesse.

You probably know the flyweight pattern, too. Maybe
that's helpful. Possibly not.

Area-zip isn't one-to-one, either. That makes it harder.
But a very focused query could get just the area codes
for the one zip code, and then it's a matter of whether
you REALLY need the city name and state name.

Sorry I'm not more helpful.


:-(

Tim