pes@bath63.UUCP (06/10/87)
We (Annie and I) are looking for a database package to use for keeping track
of our photographic slides and negatives. 'Sounds simple', I hear you say.
Not so. The problem is that the (few) available ones we've looked at so far
don't offer sufficiently powerful default values for fields, when you are
entering a new record -- which means a painful lot of typing of fields which
are virtually always predictable. I'll describe the effect we want below, in
terms of 'visible effect' -- I know some of the stuff could be handled
relationally (internally), but that's not the issue. If there are no DB
packages around which offer the features we need, a suitable alternative
would be one which will take input data from (well defined and documented)
input files, because it would be trivial to write a small data-capture
program in C. (As an aside, at the London show this spring we explained
what we wanted (but not why) to a company demonstrating a DB package, and
their initial reaction was 'why would you want to do that'? All will be
made clear.)
I should mention that in our haphazard manner things tend to happen in
bunches -- both the picture taking, and the cataloging. A first guess at
the data wanted for each picture (record), plus the appropriate default
value and some comments, would be:
Film number: I.e., this is the Nth roll of film thru the camera. This
and the next field uniquely identify the picture. By default,
should be the same as that in the previous record entered. (Once
every 36 (35, 37?) frames we'd have to reset it to number++. AND,
note that here and everywhere else, 'same as previous record' DOES
NOT mean 'constant value' -- which many seem to offer.)
Frame number: The 'edge number' of the frame, from the film. Integer in
the range 0-37 (more or less). By default, one greater than the
frame number of the last record entered.
Film type: Brand/film speed. By default the same as the in the previous
record entered -- might change (manually) when the film number
changes. Tightly coupled to film number, so could be relationalised.
Date of photo: By default, same as in previous record.
Location: By default, same as previous.
Picture-specific data field(s): Probably most sensibly defaulted to
empty, and filled in manually. Or, might be best as another
'default to previous'.
(Noting, of course, that the last 3 fields may change independently of each
other or of anything else.) For various other purposes it would be nice to
be able to say (single keystroke, more or less, *AND* (optionally) as a note
in the record template) 'initialize this record to a complete copy of the
previous one'. And (as demonstrated above) it is desirable to be able to
specify in the record template, default field values of (at least) the forms:
Some constant value.
Take value from previous record.
Value from previous record plus/minus an integer constant.
Date and/or time taken from the system clock -- should allow (at least) a
choice of DD/MM/YY or MM/DD/YY, and of 12- or 24-hour time
presentation.
Further, it would be nice to be able to pick up an arbitrary record from
within the DB, and say 'initialize the defaults pretending that this was the
previous record entered'.
It would also be nice (but not required) to have (again in the record
template) data verification, at least of the forms:
field must have a non-null value.
field must contain a valid date. (Note here that it must be possible to
accomodate at least both US MM/DD/YY and <everywhere else> DD/MM/YY)
field must be numeric.
field must be alphanumeric (plus spaces and punctuation).
(And, ideally, field must match a specified (UNIX-like) regular expression.)
Anyone found a DB which will do this? (Or, as I said, one which provides a
**documented** method for feeding in records from an ASCII file.)
Smee at AUCC (JANET)
Smee at AUCC.AC.UK (from or thru intelligent ARPA hosts)
or pes at whatever UUCP address you can derive from the header.pes@bath63.UUCP (06/10/87)
Sorry, should have mentioned, we're looking for something for personal home use, and at 'personal home use software' prices. The *really powerful* packages that cost half as much as the machine did are not of practical interest to us. Things at 'serious home software' prices could be.