Nathan,
I don't think that will scale to showing status information for a result set.
I think a compromise needs to be reached with your Systems folks.
Maybe they could review the queries?
After all, hitting Oracle directly is more efficient than any single
part of Voyager.
-Ross.
On 1/17/07, Nathan Vack <[log in to unmask]> wrote:
> On Jan 17, 2007, at 2:59 PM, Bess Sadler wrote:
>
> > As long as we're on the subject, does anyone want to share strategies
> > for syncing circulation data? It sounds like we're all talking about
> > the parallel systems á la NCSU's Endeca system, which I think is a
> > great idea. It's the circ data that keeps nagging at me, though. Is
> > there an elegant way to use your fancy new faceted browser to search
> > against circ data w/out re-dumping the whole thing every night?
>
> Sure isn't elegant, but as our Real Systems Guys don't want us to
> look at the production Oracle instance (performance worries), we've
> had pretty good luck screen-scraping holdings and status data, once
> we get a Bib ID. Ugly, but functional, and surprisingly fast.
>
> Of course, spamming the OPAC with HTTP calls certainly impacts
> performance more than just querying the database... but I digress.
>
> In a perfect world, we'd get a trigger / stored proc on the database
> server when circ status changed. In a slightly less perfect world,
> I'd just keep a connection open to the production datbase server for
> all of that.
>
> -n
>
>
|