<div dir="ltr">+1 to this idea. It would help simplify a lot of code, and make a lot of future improvements easier.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 3, 2013 at 8:38 AM, Galen Charlton <span dir="ltr"><<a href="mailto:gmc@esilibrary.com" target="_blank">gmc@esilibrary.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div class="im"><br>
On Fri, May 3, 2013 at 6:20 AM, Mathieu Saby<br>
<<a href="mailto:mathieu.saby@univ-rennes2.fr">mathieu.saby@univ-rennes2.fr</a>> wrote:<br>
> Thank you.<br>
> So, just to know, do you think it would be<br>
> 1. - a total waste of time ?<br>
> 2. - a strange idea ?<br>
> 3. - a good idea (for performance and code maintenance) ?<br>
> 4. - harmful ?<br>
><br>
> to merge the biblio and biblioitem tables ?<br>
<br>
</div>My gut feeling is #3, but a lot of testing would be needed to avoid<br>
#4. Possibly one way to reduce risk and improve testability would be<br>
to move columns over to biblio one at a time.<br>
<br>
Here are a couple additional thoughts if we undertake this:<br>
<br>
[1] We should decide whether we want to keep both bibilioitems.marc<br>
and biblioitems.marcxml. I think we can get rid of the former.<br>
<br>
[2] Even if we merge the tables, I think we should still keep the<br>
marcxml column in its own table, e.g., one called biblio_metadata:<br>
<br>
CREATE TABLE biblio_metadata (<br>
biblio_metadata_id INTEGER NOT NULL AUTO_INCREMENT; -- for the future!<br>
biblionumber INTEGER,<br>
metadata_type VARCHAR(10), -- for the future!<br>
blob LONGTEXT NOT NULL,<br>
-- and relevant FK contraints<br>
);<br>
<br>
The bits about slipping in multi-metadata-schema support aside, for<br>
many queries there's no reason to pull in largish XML columns.<br>
<br>
[3] We should see if we can drop some columns. As a rule of thumb, I<br>
suggest that if a biblio/bilbioitems column isn't referred to in the<br>
code. any of the default MARC frameworks, or the SQL reports library,<br>
it's probably not being used.<br>
<br>
Regards,<br>
<br>
Galen<br>
--<br>
Galen Charlton<br>
Manager of Implementation<br>
Equinox Software, Inc. / The Open Source Experts<br>
email: <a href="mailto:gmc@esilibrary.com">gmc@esilibrary.com</a><br>
direct: <a href="tel:%2B1%20770-709-5581" value="+17707095581">+1 770-709-5581</a><br>
cell: <a href="tel:%2B1%20404-984-4366" value="+14049844366">+1 404-984-4366</a><br>
skype: gmcharlt<br>
web: <a href="http://www.esilibrary.com/" target="_blank">http://www.esilibrary.com/</a><br>
Supporting Koha and Evergreen: <a href="http://koha-community.org" target="_blank">http://koha-community.org</a> &<br>
<a href="http://evergreen-ils.org" target="_blank">http://evergreen-ils.org</a><br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Koha-devel mailing list<br>
<a href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-community.org</a><br>
<a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" target="_blank">http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>
website : <a href="http://www.koha-community.org/" target="_blank">http://www.koha-community.org/</a><br>
git : <a href="http://git.koha-community.org/" target="_blank">http://git.koha-community.org/</a><br>
bugs : <a href="http://bugs.koha-community.org/" target="_blank">http://bugs.koha-community.org/</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jesse Weaver
</div>