Thanks, Jesse. BTW - it looks like merging them is planned for Koha 3.2 according to the developer wiki. On Wed, Jul 15, 2009 at 4:22 PM, Jesse<pianohacker@gmail.com> wrote:
2009/7/15 Library Guy <library.guy.zero@gmail.com>
Thanks Jesse. Any guess what the original thinking was for this 3-tiered structure? I can't think of any advantage to it.
James
On Wed, Jul 15, 2009 at 3:52 PM, Jesse<pianohacker@gmail.com> wrote:
2009/7/15 Library Guy <library.guy.zero@gmail.com>
What is the reasoning/advantage for assigning both a biblionumber and a biblioitemnumber? In my test database they are always identical. Would there ever be an example where they would differ, and if not, why the duplication?
James _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
In the past, it was actually a three-level hierarchy; each biblio had multiple biblioitems, which in turn had multiple items. Nowadays, biblio and biblioitems perform much the same function, but the split remains. (There was a proposal to merge the two tables, but I'm not sure what's happening with that.)
Note that biblionumber and biblioitemnumber are _usually_ equal, but it's not safe for the code to assume so. There are situations where they get out of sync.
-- Jesse Weaver
It actually allowed some fairly interesting features. For instance, if a biblio had copies both in audiobook form and print form (separate biblioitems), it allowed patrons to place a hold either on any form of that book, any copy of just one form (say, any of the copies of the audio book), or just one particular copy of the book. The original sponsors of Koha and this feature, the Horowhenua Library Trust, have called it a proto-FRBR.
That said, that particular code has aged so much that bringing back such features would be a massive undertaking (that we might have to do anyway, if FRBR ever becomes practical).
See http://www.frbr.org/ for more info on FRBR.
-- Jesse Weaver
Library Guy a écrit :
Thanks, Jesse. BTW - it looks like merging them is planned for Koha 3.2 according to the developer wiki.
yes it was planned, but don't think anyone did it yet (noone at BibLibre, Galen, someone at LibLime ? someone else -i'm almost sure no: it need a heavy work, that can probably be done only by BibLibre or LibLime - ?) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Paul, I dont think it is a critic problem and may be it gives some flexibility. In the future a more detailed discussion about all database model could be useful but for now it works. For me most important is to understand ZEBRA implementation for large databases and give more hints about instalation and configuration. For now I have had problems with indexes and searches when using no_zebra option. Advance search does not work properly mainly for UNIMARC - I have seen CCL, ABS and ATT files from ZEBRADB and a lot of chages need to be done. Regards, Rafael Antonio Citando paul POULAIN <paul.poulain@biblibre.com>:
Library Guy a écrit :
Thanks, Jesse. BTW - it looks like merging them is planned for Koha 3.2 according to the developer wiki.
yes it was planned, but don't think anyone did it yet (noone at BibLibre, Galen, someone at LibLime ? someone else -i'm almost sure no: it need a heavy work, that can probably be done only by BibLibre or LibLime - ?)
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hi, On Thu, Jul 16, 2009 at 4:16 AM, paul POULAIN<paul.poulain@biblibre.com> wrote:
Library Guy a écrit :
Thanks, Jesse. BTW - it looks like merging them is planned for Koha 3.2 according to the developer wiki.
yes it was planned, but don't think anyone did it yet (noone at BibLibre, Galen, someone at LibLime ? someone else -i'm almost sure no: it need a heavy work, that can probably be done only by BibLibre or LibLime - ?)
Right - it's a big project. Conceptually simple, but lots of queries to revise and test. Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt
participants (4)
-
Galen Charlton -
Library Guy -
paul POULAIN -
rafael.antonio@sapo.pt