 |
 |
Any Real System Guy worth their salt would know how to set up an account for you to use for SQL queries like these with read-only rights and low processing priority/throttling so there would be little to no chance of it affecting system performance. Even if they don't know, they could find out all they need to know with about 5 minutes of hax0ring the G00G13... or going to the library and getting an Oracle systems administration for dummies book if they're not into the whole internet thing. So it sounds to me like they're stonewalling you because they flat out don't know what they're doing and don't care to find out. In which cases, condolences. 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 > >