[OPEN-ILS-DEV] ***SPAM*** Unique index on biblio.record_entry.tcn_value considered

[Jason Etheridge]

> Is it too radical a notion to suggest that the biblio.record_entry.id is
> more useful and could simply take over the role of the tcn_value?

In trunk, there's actually a global setting in config.global_flag for
doing just this:
cat.bib.use_id_for_tcn

> If I'm beating a dead horse here, I apologize. And if there's a fundamental
> utility to the tcn_value that I've missed, I'm anxious to have that cleared
> up.

This is my opinion, and I've always been hazy on TCN's:

In the case of PINES, TCN's got promoted as a concept more than they
might have otherwise because 1) Unicorn had separated TCN's (flex
keys) from internal identifiers and 2) PINES would actually ascribe
meaning to records based on what the TCN looked like (because their
database has so many originating sources with different quality, etc.
and those sources had different patterns for their TCN values).

In Unicorn, it was easier to get at this externalized TCN than the
001/003/035 in the MARC (which were horribly inconsistent).  This
could have been trivially different in Evergreen, but this was one
kludge we didn't catch (didn't know better) when asking PINES how they
wanted Evergreen to work.  TCN's were these magical things, rather
than opaque identifiers.

-- 
Jason Etheridge
 | VP, Tactical Development
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  jason at esilibrary.com
 | web:  http://www.esilibrary.com