[Koha] Koha Newbie Questions

[Joshua M. Ferraro]

Hi Jon, 

Just a quick note to address your question about the dual database design question. 
In Koha version 2.2.x, we used a design with only one relational database at the 
back-end. The database design was structured to allow us to divide up a MARC 
record into its parts (fields, subfields, terms) to allow us to query on any/all of 
those parts using SQL. 

The problem with this design is that it doesn't scale well. Relational databases do 
a great job of capturing transactions and storing data, but aren't too good at 
allowing complex query operations on sets and subsets of that data. So for the 
next version of koha (3.0), and the one that's been making the news lately, 
we've integrated a textual database engine called Zebra (http://indexdata.dk/zebra) 
that allows us to index the records (MARC, Holdings, Authorities, etc.) and 
allow access to them via standard query languages and protocols (such as 
Z39.50, SRW/U, CQL, CCL, PQF). The data is still stored in a back-end 
relational database, the index is just one way to get at it ... it's primarily a 
'read-only' database and doesn't contain authoritative data. 

Generally speaking, there would not be a need to 're-index' Zebra, or to have 
any periodic patch process to update the index, unless you drastically altered 
the search index configuration. The index is updated in real time along with 
transactions that are stored in the relational tables. In the case where you did 
need to re-index, I've seen Zebra crunch through 7 million records in about 
45 minutes. 

This is really just a partial answer, because I've got to head out to a 
conference I'm attending in Champaign IL this week :-). Let us know if 
it answers some of your questions, and if you have additional ones. 

Cheers, 

-- 
Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE 
President, Technology migration, training, maintenance, support 
LibLime Featuring Koha Open-Source ILS 
jmf at liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS 

----- Original Message ----- 
From: "Jon Bek" <jonbek at yahoo.com> 
To: koha at lists.katipo.co.nz 
Sent: Wednesday, September 12, 2007 10:27:23 AM (GMT-0500) America/New_York 
Subject: [Koha] Koha Newbie Questions 

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 

View this message in context: Koha Newbie Questions 
Sent from the Koha - Discuss mailing list archive at Nabble.com. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.katipo.co.nz/pipermail/koha/attachments/20070912/83e690fc/attachment.htm