Thoughts on manual database design?

[Jay Jaeger]

On 9/22/2015 10:12 PM, Zane Healy wrote:
> My recommendation would be to ensure compatibility with the MARC database format.  Even if you don't include all the fields, the fields you do have should be compatible.  If you look you should find Open Source projects that are MARC compatible.  It's been several years since I looked into this, and then I was populating a MARC database from a massive Excel spreadsheet.
> 
> Zane
> 
> 
> 

I checked quite a bit of it out, including:

http://www.loc.gov/marc/bibliographic/
http://www.loc.gov/marc/umb/um01to06.html
https://en.wikipedia.org/wiki/MARC_standards
https://en.wikipedia.org/wiki/MARC_standards#MARC_21
http://www.loc.gov/standards/marcxml/xml/spy/spy.html

MARC does not seem at all applicable to my goals - MARC is not at all a
"database" format.   Instead it is a (very complicated and cumbersome)
format standard for binary or (in the case of MARCXML) XML transmission
(interchange) of a very small portion of the sort of information I would
have in my database (like, the publisher and title).  The standard is
for records that have been folded into a single binary or XML
representation of the metadata about a publication.  Furthermore, and
most importantly, the standard doesn't really address the
characteristics of individual fields at all (aside from encoding special
characters, which I would not want to do at all). Finally, MARC and
MarcXML are *way* more baroque and complicated than I would ever want to
deal with (see my original statement).

Trying to apply MARC to my situation would seem to be akin to taking a
Cessna private plane to a major airline hanger for maintenance.  Yeah,
it could be done: a great cost and expense, with the possibility that
due to mismatch in experience, potentially fatal mistakes might be made.

The info on the Library of Congress "authority records" for identifying
publishers / manufacturers was interesting.  But, really, the important
thing that points to is to have those sorts of fields be constrained to
defined values so that a consistent set is used (instead of just free
form text), which I had already planned to do.

So, almost no value for mountains of work.

The value of MARC would be if someone wanted to take all of my documents
at some point and send them to a real library to include in its catalog.
 Then one might transform the rows of my database into MarcXML.  Not
something I care to do or worry about.

(BTW, My memory of that acronym is "Machine Assisted Resource
Coordinator", a small-sized Unix work-alike developed by Ed Ziemba (RIP)
using Leor Zolman's BDS C compiler).

JRJ