Since you have the CataloguingLog turned off, you should see a net gain in the size of the database, both in Koha and in Zebra/Solr. Though you probably won't notice the difference in Koha since the tables are InnoDB, which doesn't reduce file size in most cases. In the frontend you probably won't notice much difference I would expect. Since you indicate the fields are hidden in the OPAC the biggest difference will be in the work of your cataloguing staff. I don't know if you have discusses the idea with them, sometimes cataloguers prefer to have more information available (even if unused), sometimes they prefer less. More information could mean better record matching in searches and record merges. Less information could mean more efficient cataloguing since the staff doesn't need to keep as much information at hand while cataloguing. I tend to prefer keeping the information, and hide it in the staff interface if it bothers someone, but that's my preference. As far as drawbacks to doing such changes in the backend there is one big drawback. The metadata / marc fields need to be rebuilt and the search engine needs to be reindexed after any changes by hand to the database. That is the reason I tend to do any big batch modifications by setting up a script that uses the Koha modules ( the C4 / Koha api ). That way Koha itself will take care of that for me. One final note, the difference in size from removing those fields is likely to be small, in the order of a few hundred megabytes at most would be my guess. On Wed, Aug 1, 2018 at 7:00 AM Cab Vinton <bibliwho@gmail.com> wrote:
Hi, All --
Koha's Batch Record Modification (BRM) tool makes it very easy to make large-scale changes to the catalog. And we know that many catalogers like to have their records just so :-)
Is there a cost in overhead, however, to making such changes?
For example, if a catalog of 150,000 records contains 75,000 unwanted MARC fields, would you delete them, even if they're not displayed in the OPAC or otherwise interfering w/ functionality?
In particular, I'm wondering whether using the BRM tool involves the creation of new data so that there's no real net gain w/ respect to the goal of having a "cleaner" database. (In our case, we've turned off the CataloguingLog system preference.)
Along the same lines, are there any advantages to doing large-scale batch process via the backend instead, i.e., as opposed to w/ the built-in staff tools such as BRM? (I'm assuming there's no issue w/ using such tools to work w/ much smaller subsets of records.)
Thanks in advance for any guidance.
All best,
Cab Vinton, Director Plaistow Public Library Plaistow, NH _______________________________________________ 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/
-- Michael Hafen Washington County School District Technology Department Systems Analyst