http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 --- Comment #1 from Galen Charlton <gmcharlt@gmail.com> 2010-11-24 19:05:30 UTC --- A suggestion - rather than widening the field, if bibliographic fields need to be stored outside of the MARC record for display, performance, or caching reason, multiple values would be better handled by keeping them in a separate table, something like: biblio_attributes: biblionumber (foreign key) code (identifies the attribute, i.e., 'isbn', 'issn', etc.) seqno (sequence number, if needed) value -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au Version|rel_3_4 |master --- Comment #3 from David Cook <dcook@prosentient.com.au> --- I would like to breathe some life back into this bug. I've noticed that the detail pages of the catalogue in the OPAC and the staff client go straight to the MARC to get the ISBNs, but the database field is still used in areas like the "Receipt Summary" in acquisitions after receiving new items. While it may be trivial, multiple isbns are getting cut off, so that they do not display properly. The easiest solution would be to lengthen like Fridolyn has suggested. However, I think I understand Galen's suggestion to make a different table instead to work with multiple values. After all, it's not good practice to be putting multiple values in a single field, right? That said, a new table might be overkill, because ISBN might be the only field in biblioitems that contains multiple values. I'm not 100% sure on this one, as I just took a quick look glance through some sample data. Thoughts? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathieu.saby@univ-rennes2.f | |r --- Comment #4 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- If someone is working on that bug, please consider applying the same treatment to EAN field in biblioitems table. You say it is not good to have multiple values in a field, but this occurs elsewhere. For example in biblio table, for author, unititle and title (at least in UNIMARC, because they are mapped to repeatable subfields...). Should we do something for that ? M. Saby Rennes 2 University -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

...

I know, I was just reacting to David Cook's remark "After all, it's not good

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 --- Comment #6 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- author, title and unititle are mediumtext, they can accept 16 millions of characters. practice to be putting multiple values in a single field, right? " But if it is only a "good practice", I suppose it is not harmfull to have several 200$a (several titles by the same author, in collective works) mapped in biblio.title ? Mathieu -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 --- Comment #8 from David Cook <dcook@prosentient.com.au> --- (In reply to Galen Charlton from comment #7)

(In reply to David Cook from comment #3)

...

That said, a new table might be overkill, because ISBN might be the only field in biblioitems that contains multiple values. I'm not 100% sure on this one, as I just took a quick look glance through some sample data.

Well, there are a *lot* of fields that are repeatable and where you might well want to display and search on all repeats for a record. Off the top of my head:

- EAN/UPCs, as mentioned by Mathieu - arbitrary record identifiers (e.g., from the MARC21 035 field) - chapter and part titles - languages of the work

Good point, Galen. When I first wrote my comment, I wasn't aware that there were other cases of repeatable MARC fields being put in a single database field with a pipe separator. However, after reading the other comments and taking a more thorough look, I see that more and more. Perhaps a new table, following the model you suggested in 2010, would be the best idea. However, if we were to have a "biblio_attributes" table, might it make sense to drop the biblioitems table and reduce the scope of the biblio table? That is to say, all bibliographic attributes (not only 'isbn' and 'issn' but also 'title', 'author', 'notes', and other attributes from both the biblio and biblioitems tables) would be stored in "biblio_attributes", while the "biblio" table would still exist with system specific attributes/data such as the 'biblionumber', 'frameworkcode', 'timestamp', and 'datecreated' fields. Conceptually, I like that separation of data. In terms of killing MARC, it might be an idea to make yet another table called "biblio_records" where the record is stored in a field (i.e. blob) and a metadata descriptor is recorded in another field. However, it would take a massive re-write to the Koha code to make that a reality, no? Also, by putting all that data in to one table, might we suffer some large performance hits for databases with huge amounts of bib records? -- These are just musings on my part. I haven't designed enough databases to know what the best practice is in terms of performance. I wonder sometimes about how much we gain from using the relational database to store bibliographic data. Currently, are we not storing bibliographic data in 4+ places? The biblio table, the biblioitems table, the MARC blob in the biblioitems table, the MARCXML blob in the biblioitems table, and finally the Zebra database? Both in terms of killing MARC and improving data integrity (and perhaps performance), might it not make sense to reduce the number of places we're storing data? Is the idea of storing data in the relational database to improve the speed of retrieval? Do we actually gain speed? No pattern has emerged to me in terms of deciding when to use the MARC record and when to use the database as the source of data in a given script. I know we have the "mod" scripts which ensure data integrity, but I can't help but think that there must be a better way of storing and retrieving bibliographic data... Sorry for the long comment! I would almost tl;dr it, but I think they're valid questions. "biblio", "biblio_attributes", and "biblio_records"? "biblio", "biblioitems", "biblio_attributes"? "biblio","biblio_records"? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com Assignee|gmcharlt@gmail.com |kyle@bywatersolutions.com -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris@bigballofwax.co.nz --- Comment #12 from Chris Cormack <chris@bigballofwax.co.nz> --- We never actually use biblioitems.issn for much of anything, certainly not if using XSLT -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 Fridolin SOMERS <fridolyn.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #25491|0 |1 is obsolete| | --- Comment #15 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 25492 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25492&action=edit Bug 5377 [QA Followup] - Alter deletedbiblioitems to match biblioitems -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #25492|0 |1 is obsolete| | --- Comment #18 from Jonathan Druart <jonathan.druart@biblibre.com> --- Created attachment 25494 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25494&action=edit Bug 5377 [QA Followup] - Alter deletedbiblioitems to match biblioitems Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 --- Comment #20 from Jonathan Druart <jonathan.druart@biblibre.com> --- (In reply to Kyle M Hall from comment #16)

QA'ers, if you feel for some reason the deletedbiblioitems table *should* have an issn index, just deprecate the followup, and restore the previous iteration of it.

I didn't see your comment when I submitted my QA patches. In my opinion, if the index is not in use, it is useless to add it. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to Master CC| |gmcharlt@gmail.com --- Comment #21 from Galen Charlton <gmcharlt@gmail.com> --- Pushed to master. Thanks, Kyle! -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 --- Comment #23 from Doug Dearden <dearden@sarsf.org> --- Further investigation on this showed something interesting. I have three databases - main, image, and archive. The original DB is main, later I created image and still later archive - so archive was created on a newer version of Koha than the other two. The update to archive did not throw these errors. When I look at a pre-update version of the biblioitems table in the main and image DBs there are two indexes for issn - one called issn, the other issn_idx . Looking at a post-update version there is only issn_idx - no issn or isbn indexes, and the isbn and issn fields are still varchar(30) and varchar(9). I think adding $dbh->do("ALTER TABLE biblioitems DROP INDEX issn_idx"); to the right spot in updatedatabase.pl probably fixes this. I don't know why that old index was there on my main and image databases. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 --- Comment #25 from Jorge de Cardenas <jdeca@smfpl.org> --- In addition to the issn_idx index I also have isbnidx index. I will be dropping these and later retest. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 Mason James <mtj@kohaaloha.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rel_3_16_candidate | CC| |mtj@kohaaloha.com Status|Pushed to Master |Pushed to Stable -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.