Simon Josefsson <jas(_at_)extundo(_dot_)com> writes:
pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz (Peter Gutmann) writes:
I've thought about this a bit in the past (I use databases to store
other types of keys) but because of the free-form association of
different bits and pieces of keys with identifying information I
can't think of any easy way to do it unless you use a multi-level
lookup. That is, you can't do a:
SELECT key FROM table WHERE email = foo
because there could be an arbitrary number of email addresses attached to a
key, and there could be an arbitrary number of keys associated with an email
address. So you need something like:
SELECT keyID FROM indexTable WHERE email = foo
SELECT key FROM sigKeyTable WHERE keyID = foo
which isn't very efficient (multiple tables, multi-level lookups, etc etc).
Have you tried this and found that performance is the most performance
critical area?
I hadn't really checked it, because the code could end up plugged into almost
any database type (via ODBC) on any kind of system, I wasn't sure that results
for one particular environment would be terribly useful. For example if you
can tell the back-end (via SQL hinting) to use a hashed index held in RAM it'd
be pretty quick. If you end up with a linear scan on disk, it'd be pretty
awful.
(The database contained the equivalent of ~2GB PGP keyrings worth of data,
although the machine had enough memory to store the entire database in RAM.)
Yeah, well that would help a bit :-).
Peter.