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 <mailto: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 <http://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 <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/
