[Koha-devel] Proposed "metadata" table for Koha

[Jesse]

If we do this, I very much vote for doing it the way Tomas is describing
(aka, storing entire chunks of metadata as blobs). Koha 2.2 had a
row-per-subfield structure kind of like what you're suggesting, and it
required a lot of monkeying around to accurately represent all the vagaries
and ordering of MARC subfields. It was also (from what I remember) quite a
disk hog.

2015-11-30 15:42 GMT-07:00 David Cook <dcook at prosentient.com.au>:

> Just to contradict myself a bit, it might be worth mentioning that Zebra
> will do a better job with ISSN and ISBN matching, as I think it normalizes
> those strings. That would be nicer than a regular string matching SQL query…
>
>
>
> David Cook
>
> Systems Librarian
>
> Prosentient Systems
>
> 72/330 Wattle St, Ultimo, NSW 2007
>
>
>
> *From:* Tomas Cohen Arazi [mailto:tomascohen at gmail.com]
> *Sent:* Tuesday, 1 December 2015 1:20 AM
> *To:* David Cook <dcook at prosentient.com.au>
> *Cc:* koha-devel <koha-devel at lists.koha-community.org>
> *Subject:* Re: [Koha-devel] Proposed "metadata" table for Koha
>
>
>
>
>
>
>
> 2015-11-29 21:52 GMT-03:00 David Cook <dcook at prosentient.com.au>:
>
> Hi all:
>
>
>
> For those not following along at
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662, we’ve
> recently started talking about the possibility of adding a “metadata” table
> to Koha.
>
>
>
> The basic schema I have in mind would be something like: metadata.id,
> metadata.record_id, metadata.scheme, metadata.qualifier, metadata.value.
>
>
>
> The row would look like: 1, 1, marc21, 001, 123456789
>
>
>
> It might also be necessary to store “metadata.record_type” so as to know
> where metadata.record_id points. This obviously has a lot of disadvantages…
> redundant data between “metadata” rows, no database cascades via foreign
> keys, etc. However, it might be necessary in the short-term as a temporary
> measure.
>
>
>
> Of course, adding “yet another place” to store metadata might not seem
> like a great idea. We already store metadata in biblioitems.marcxml (and
> biblioitems.marc), Zebra, and other biblio/biblioitems/items relational
> database fields. Do we really need a new place to worry about data?
>
>
>
> I think we should have a metadata_record table storing the serialized
> metadata, and more needed information (basically the fields
> Koha::MetadataRecord has...) and let the fulltext engine do the job for
> accessing those values.
>
>
>
> The codebase is already too bloated trying to band-aid our "minimal" usage
> of the search engines' features. Of course, while trying to fix that we
> might find our search engine has problems and/or broken functionalities
> (zebra facets are so slow that are not cool). But we should definitely get
> rid of tons of code in favour of using the search engine more, and probably
> have QueryParser be the standard, having a driver for ES...
>
>
>
> --
>
> Tomás Cohen Arazi
>
> Theke Solutions (http://theke.io)
> ✆ +54 9351 3513384
> GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 
Jesse Weaver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20151130/ec5274ae/attachment.html>