[EP-tech] EPrint datasets, the advisability of using, and access to the tables

[Ian Stuart]

OK.... Here in Repository Junction Broker land, I'm creating a 
sub-service to allow people to register to receive "postcards" about 
records that *could* have gone into an IR, had things been set up to do 
transfers.... the idea being that either this will trigger you to 
actually set up as a recipient of data, or you'll go and check you've 
already got the records.... and harvest them somehow, if you don't.

Anyway - for various reasons (primarily that RJB is actually 
load-balanced fully read/write across two servers), the details for the 
"postcards" need to be stored in a database.
I have three options here:
1) Totally separate database, and just do SQL (means I need to set up 
failover replication and all that malarkie)
2) Add the tables to the EPrints database, but just use simple SQL to 
access them
3) Actually create a new data-object* for these registrations.

Option 3 has some interesting benefits - I can use the EPrints 
infrastructure to access and manage the data (which is good, as I'm 
already using EPrints to manage the web pages), and all the 
relationships are automatically handled for me.
It also raises some questions: can I create objects where access is NOT 
controlled by registered user access? (ie, I just want my scripts to 
access the tables, not logged in users); are the overheads of creating 
new data-objects high for what is essentially 3 tables, and just 
hand-coding the SQL would be easier?

.... oh, the joys of TMTOWTDI! ;-)

[*] It'll probably need to be 2 data-objects: One for the subscriber & 
the email(s) they want information sent to, and another for the 
repositories that each email wants to receive updates about....
-- 

Ian Stuart.
Developer: ORI, RJ-Broker, and OpenDepot.org
Bibliographics and Multimedia Service Delivery team,
EDINA,
The University of Edinburgh.

http://edina.ac.uk/

This email was sent via the University of Edinburgh.

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.