Hi, On Fri, May 3, 2013 at 6:20 AM, Mathieu Saby <[email protected]> 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. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: [email protected] direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ Koha-devel mailing list [email protected] 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/
