<html><head><style type='text/css'>body { font-family: 'Times New Roman'; font-size: 12pt; color: #000000}</style></head><body>Hi Jon,<br><br>Just a quick note to address your question about the dual database design question.<br>In Koha version 2.2.x, we used a design with only one relational database at the<br>back-end. The database design was structured to allow us to divide up a MARC<br>record into its parts (fields, subfields, terms) to allow us to query on any/all of<br>those parts using SQL.<br><br>The problem with this design is that it doesn't scale well. Relational databases do<br>a great job of capturing transactions and storing data, but aren't too good at<br>allowing complex query operations on sets and subsets of that data. So for the<br>next version of koha (3.0), and the one that's been making the news lately,<br>we've integrated a textual database engine called Zebra (http://indexdata.dk/zebra)<br>that allows us to index the records (MARC, Holdings, Authorities, etc.) and<br>allow access to them via standard query languages and protocols (such as<br>Z39.50, SRW/U, CQL, CCL, PQF). The data is still stored in a back-end<br>relational database, the index is just one way to get at it ... it's primarily a<br>'read-only' database and doesn't contain authoritative data.<br><br>Generally speaking, there would not be a need to 're-index' Zebra, or to have<br>any periodic patch process to update the index, unless you drastically altered<br>the search index configuration. The index is updated in real time along with <br>transactions that are stored in the relational tables. In the case where you did<br>need to re-index, I've seen Zebra crunch through 7 million records in about<br>45 minutes.<br><br>This is really just a partial answer, because I've got to head out to a <br>conference I'm attending in Champaign IL this week :-). Let us know if<br>it answers some of your questions, and if you have additional ones.<br><br>Cheers,<br><br>-- <br>Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE<br>President, Technology migration, training, maintenance, support<br>LibLime Featuring Koha Open-Source ILS<br>jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS<br><br>----- Original Message -----<br>From: "Jon Bek" <jonbek@yahoo.com><br>To: koha@lists.katipo.co.nz<br>Sent: Wednesday, September 12, 2007 10:27:23 AM (GMT-0500) America/New_York<br>Subject: [Koha] Koha Newbie Questions<br><br>
Hello, and please forgive me if I haven't navigated to precisely the right forum for Koha Newbie questions:
I am the IT Project Manager for a very large public school district currently running the Sagebrush (now Follett) Accent product, which in turn uses the Unicorn engine (2003 version) created by Sirsi.
On of our largest challenges with the architecture of our existing product is that the architecture is dependent upon two databases: BRS (for full text search) and OPAC. Nor does it appear that the division of labor between BRS and ORACLE is clean -- we can see that there are patron user indexes and other objects used by BRS that make no sense if the tasks were segregated as simply as they have been portrayed.
Due to the number of libraries we serve (680+) and the number of titles in our OPAC (7,000,000+), a batch job which should run nightly to synchronize BRS temp and permanent indices and Oracle records very often cannot complete after hours. This batch (ADUTEXT) may not run during business hours, as it interferes with ordinary central cataloging tasks, as well as certain tasks (inventory, adding brief marc records, importing new copies of arriving shipments) in the field.
I am interested in evaluating Koha, but am concerned by the touted "Dual Database" nature of Koha. This sounds very much like a trip down the same dead-end street we've encountered with Accent.
Does anyone have insight & experience to share with me about batch or periodic processes required to maintain Koha (especially "nightly" stuff), or a better understanding of the the Koha architecture, and why it would or would not pose similar problems for an operation our size?
Thanks in advance!
-Jon
<br><hr align="left" width="300">
View this message in context: <a href="http://www.nabble.com/Koha-Newbie-Questions-tf4429659.html#a12636666" target="_blank">Koha Newbie Questions</a><br>
Sent from the <a href="http://www.nabble.com/Koha---Discuss-f14390.html" target="_blank">Koha - Discuss mailing list archive</a> at Nabble.com.<br>
</body></html>