[Tfug] more RDBMS

[Bexley Hall]

Hi,

--- Terence Rudkin <trudkin at gmail.com> wrote:

> On 10/22/07, Bexley Hall <bexley401 at yahoo.com>
> > I *hope* these are simple RDBMS questions (even
> > though the simple ones never actually *prove* to
> > be so!  :< )
> >
> > I'm looking for an inexpensive (computationally)
> > way to see if a "database", or, specifically, a
> > certain *table* has been *changed* since the last
> > time I "noticed" it.  I.e. a way of stat(2)'ing
> > it that is *portable* (i.e. lives in SQL land).
>
> Some databases have that as a feature that the last
> update can be an
> inexpensive query, even if the database is not. 

I'm not too concerned with the cost of the query,
per se, but, rather, the overall cost of the
query plus result.

The *data* in the last update is a "BLOB".  I really
don't want to be pulling down these big objects if
I can *know* that the cached copy that I have
client-side is up-to-date.

> Some also have in the
> data dictionary information of last update to a

OK.  But I suspect that leads me down the road
of proprietary implementations...

> table.   But you can
> roll your own solution with a table LAST_TAB_UPDATE,
> with two columns
> TABLE_NAME, LAST_CHANGE .  Then if updates are all
> done
> programmatically update both tables, else if
> TRIGGERS are supported
> then on update or insert update the table.  The
> inexpensive read of
> the update table can prevent the need of a more
> expensive refresh.

Ah, OK.  That works.  I wouldn't have thought of
that sort of approach!  <:-)

> You asked  for a SQL answer, but a framework like
> Hibernate handles
> this automagically.
 
> > In a VERY LIGHT DUTY APPLICATION, how foolish is
> > it for clients to periodically issue queries of
> > the RDBMS like:
> >   SELECT now;
> > instead of tracking time "locally", themselves?
> > I.e., use the RDBMS as a time reference instead
> > of burdening the individual clients (which, in
> > this case, are kiosks) with the overhead of a
> > "real" time service?
> the database should use the same time service as the
> client.  So an
> infrequent sanity check from client to server would
> be my solution.

The client's are very dumb.  Implementing a timed
client on them would mean a sh*tload of extra work for
me for very little gain.  Hence the *hack* of just 
asking the server routinely and letting *that* be
my reference.

Thx,
--don



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com