Print

Print




The strong point of relational databases is when you have a less than a couple of dozen different kinds of things (i..e books, staff, patrons, circ desks, loan lengths) each of which is very similar and interacts with others in highly standardised ways (loans, requests, etc) and no new kinds of things or kinds of interactions are allowed. Data checking / validation / schemas are easy in this approach, because of the small number of possible combinations and the closed world assumption. Relational databases typically handle recursion poorly.

The strong point of tuple databases is when you have complex interactions between things, those things sometimes play unexpected roles and much of the data is non-local. The lack of explicit schemas and greater flexibility of data representation makes data checking and validation much more challenging. Tuple databases typically handle recursion very well.

Bibliographic examples of things that are typically hard to represent in a relational database might be conflation of work and author (the library has a holding which is a text generating program, a separate holding is a transcript generated by that program); third party-sourced resources which have a loan period specified per-item by the third party; or works whose authors are pseudonymous but reachable via an anonymity-preserving internet protocol (i.e. via Tor). Representing these in a relational database usually involves throwing away information that doesn't fit the relational data model (data is lost); representing these in the tuple model usually involves adding extra relationships not explicitly anticipated in the original schema (data is present but may not be seen / acted on by existing functionality).

Loosely put, all the stuff you've ever thought of putting in a human-readable note field, is now a candidate for adding to the machine-actionable relationships.  If you've never had any information that you wanted to store in a note field, the switch to a tuple model isn't going to gain you anything, if you have, it is likely to.

cheers
stuart
 

> So, the thought is not using a relational database for storing the data? I keep hearing that relational database is inappropriate for storing library data, but, I don’t see how library data is any different than any other kind of data that has no problem being stored relationally.