I'm all for seeing biblioitems disappear. The only bib of data that I reference (in migration or support work) is the biblioitems.itype and biblioitems.marcxml. A lot of the other fields appear to be dupes of items (volumenumber, volumedate, etc.) or more correctly belong in biblio (isbn, publication year, etc). I like Galen's idea of the biblio_metadata table and dropping (or moving as appropriate) columns from biblioitems as seems appropriate. Joy Nelson Director of Migrations ByWater Solutions <http://bywatersolutions.com> Support and Consulting for Open Source Software Office: Fort Worth, TX Phone/Fax (888)900-8944 What is Koha? <http://bywatersolutions.com/what-is-koha/> On Fri, May 3, 2013 at 9:38 AM, Galen Charlton <gmc@esilibrary.com> wrote:
Hi,
On Fri, May 3, 2013 at 6:20 AM, Mathieu Saby <mathieu.saby@univ-rennes2.fr> wrote:
Thank you. So, just to know, do you think it would be 1. - a total waste of time ? 2. - a strange idea ? 3. - a good idea (for performance and code maintenance) ? 4. - harmful ?
to merge the biblio and biblioitem tables ?
My gut feeling is #3, but a lot of testing would be needed to avoid #4. Possibly one way to reduce risk and improve testability would be to move columns over to biblio one at a time.
Here are a couple additional thoughts if we undertake this:
[1] We should decide whether we want to keep both bibilioitems.marc and biblioitems.marcxml. I think we can get rid of the former.
[2] Even if we merge the tables, I think we should still keep the marcxml column in its own table, e.g., one called biblio_metadata:
CREATE TABLE biblio_metadata ( biblio_metadata_id INTEGER NOT NULL AUTO_INCREMENT; -- for the future! biblionumber INTEGER, metadata_type VARCHAR(10), -- for the future! blob LONGTEXT NOT NULL, -- and relevant FK contraints );
The bits about slipping in multi-metadata-schema support aside, for many queries there's no reason to pull in largish XML columns.
[3] We should see if we can drop some columns. As a rule of thumb, I suggest that if a biblio/bilbioitems column isn't referred to in the code. any of the default MARC frameworks, or the SQL reports library, it's probably not being used.