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 <dc...@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:tomasco...@gmail.com] > *Sent:* Tuesday, 1 December 2015 1:20 AM > *To:* David Cook <dc...@prosentient.com.au> > *Cc:* koha-devel <koha-devel@lists.koha-community.org> > *Subject:* Re: [Koha-devel] Proposed "metadata" table for Koha > > > > > > > > 2015-11-29 21:52 GMT-03:00 David Cook <dc...@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@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
_______________________________________________ Koha-devel mailing list Koha-devel@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/