biblio and biblioitems
Hello Could you tell me if there is some reason for keeping bibliographic information in 2 tables (biblio / biblioitems). I don't see any case where 1 biblionumber could match more than 1 biblioitemnumber. Maybe it is an heritage of the first versions of Koha? M. Saby -- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
Mathieu Saby schreef op za 27-04-2013 om 13:42 [+0200]:
Maybe it is an heritage of the first versions of Koha?
Apparently it's a historical artefact from the days before Koha supported MARC, and was able to use a FRBR style structure (i.e. one title can have a number of different forms, and they can have their own items.) -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
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 ? M. Saby Robin Sheat a écrit :
Mathieu Saby schreef op za 27-04-2013 om 13:42 [+0200]:
Maybe it is an heritage of the first versions of Koha?
Apparently it's a historical artefact from the days before Koha supported MARC, and was able to use a FRBR style structure (i.e. one title can have a number of different forms, and they can have their own items.)
------------------------------------------------------------------------
_______________________________________________ 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/
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
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. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com 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
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.
Galen Charlton a écrit :
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.
Maybe the problem is the way some subs are written, getting all the columns of biblio and biblioitems ? If they do not contain SELECT * but SELECT a,b,c,d..., is it necessary to put marcxml in an other table ? I know quite nothing in SQL, so excuse me if it is a bad question... M. Saby
[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: gmc@esilibrary.com 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
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
On Fri, May 3, 2013 at 7:53 AM, Mathieu Saby <mathieu.saby@univ-rennes2.fr> wrote:
Galen Charlton a écrit : Maybe the problem is the way some subs are written, getting all the columns of biblio and biblioitems ? If they do not contain SELECT * but SELECT a,b,c,d..., is it necessary to put marcxml in an other table ?
I know quite nothing in SQL, so excuse me if it is a bad question...
No, that's a good question. Specifying only the columns needed for a given query does indeed reduce the amount of data that gets moved around. On the other hand, there are a few core queries that need everything from biblio and biblioitems *except* the marcxml, so for those cases writing "SELECT *" is easier than having to update the query every time a column is added. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com 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
Le 03/05/2013 16:38, Galen Charlton a écrit :
[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 ); +1 for this idea. It would be our first step to a full support of FRBR : biblio(items) containing only "basic" information, that are absolutely required everywhere and that should not require any meta-data decoding while the biblio_metadata would contain the raw record. The metadata_type telling how it must be accessed.
-- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper
Hi, On Fri, May 3, 2013 at 9:24 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
It would be our first step to a full support of FRBR : biblio(items) containing only "basic" information, that are absolutely required everywhere and that should not require any meta-data decoding while the biblio_metadata would contain the raw record. The metadata_type telling how it must be accessed.
And in particular, what I have in mind is that metadata_type would represent the applicable schema (and perhaps serialization), e.g., for what Koha supports now, the list of metadata types would be something like: marc21-marcxml unimarc-marcxml normarc-marcxml Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com 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
+1 to this idea. It would help simplify a lot of code, and make a lot of future improvements easier. On Fri, May 3, 2013 at 8: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.
Regards,
Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com 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 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
participants (6)
-
Galen Charlton -
Jesse -
Joy Nelson -
Mathieu Saby -
Paul Poulain -
Robin Sheat