A few thoughts on databases and their recovery in general as I think
it might help to understand how they work when used in photography.
I'm going to get a bit on the basic side here, but I think it might
help some reading this.
Relational databases consist of a series of files called tables. They
are called relational as fields in one table will point to (are linked
to) records in other tables. IE, table one is related to table two
through field 3 where for example field 3 is the photographer's name
or it could be key words. Doing this on key words can greatly speed
searches.
It may a bit of an over simplification, but Lets say table one is the
table containing the image IDs and information such as you can bring
up by right clicking on an image and selecting properties. In table
one you create a record that has the field names match the field names
in the properties window. From there it is relatively easy to write a
routine to import the contents of the Properties into the record. OTOH
most databases will already do this without the user having to do more
than click on a few buttons.
Now you create another table with the photographer's names. In the
case of a family this might only be 2 or 3 individuals. Each record
would contain the desired information about the photographer. Were
you cataloging photos for a number of photographers as in a museum, or
show this would make a lot more sense.
But for now we have one table that contains the photo IDs with the
pertinent information and the photographers name. We have a second
table that contains the information on the photographers.
The next step is to identify and activate the link between the name
field for the photos and the table containing the photographers. NOW
the database is relational in the two tables are related.
IF we add a new photo to the one table and it's by a new photographer,
the database will automatically open a new record for that
photographer so you can fill in the information.
There are several ways to back up the database. It can be backed up as
a whole, or the individual tables can be exported. You can export the
tables in a number of fashions, but they will be text files unless you
back up the table in its entirety. Some databases can get pretty
confusing at this point.
You have the most common which is comma delimited, then space
delimited, columnar delimited, tab delimited, and space delimited.
These are the most common and should be pretty much self explanatory.
For instance the comma delimited file has a comma separating each
field from the next. In columnar delimited each field is located in a
column dedicated to that field only.
Having gone this far we can now export all the record in the photo
table as text that is comma delimited. We can then export the record
from the photographers table in the same manner.
We now have two text files that are completely independent of each
other and easily readable. It should also be readily apparent if you
wish to create a database using these two files how they are related.
You create a new data base, create the tables and import the each file
to the proper table. The only thing left is to recreate the link
between the tables.
Programs such as "Thumbs Plus" do this work for you and a number of
other things as well.
Sooo... It's easy to find the information and it's easy for databases
to import it. You could conceivably create a table for each of the
image properties fields including remarks. Any time the information
for multiple images is the same in a particular field that field can
become a link to another table containing the information rather than
having to write the information into that field for every image.
OTOH the more tables the photographer uses the more difficult it
becomes to recreate the original database from a group of text files.
Incidentally these files are usually called flat files in that they
are a flat text file that contains a number of lines of text and
connect to nothing else. They are "stand alone".
As an aside, in the "old days" they used to take a series of tables in
VMS that were flat files and create links to other tables in the
search statements.. They served the same purpose as a relatively
simple relational database, but were called "Forced Relational
databases". I've seen them with more than a 100 tables, some of which
had well over a hundred fields, while the database contained millions
of records. The links, which really didn't exist" in the relational
sense, were in SQL statements which might be a bit complicated to
explain here and I'm not sure I remember them all..
Now you know whey I'm trying to address this *stuff* on the web
page<
)
Roger Halstead (K8RI & ARRL life member)
(N833R, S# CD-2 Worlds oldest Debonair)
www.rogerhalstead.com