Re: Relational databases

Tim Howes <tim@umich.edu> Wed, 24 January 1996 19:39 UTC

Message-Id: <199601241437.JAA06955@terminator.rs.itd.umich.edu>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tim Howes <tim@umich.edu>
To: Paul Barker <P.Barker@cs.ucl.ac.uk>
cc: osi-ds@cs.ucl.ac.uk
Subject: Re: Relational databases
In-reply-to: Your message of "Mon, 22 Jan 1996 10:39:32 GMT." <535.822307172@cs.ucl.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 24 Jan 1996 09:37:46 -0500

> From:    Paul Barker <P.Barker@cs.ucl.ac.uk>
> To:      osi-ds@cs.ucl.ac.uk

>    Can anyone point me at either:
> 
> o theoretical papers
> 
> o technical reports on experiences
> 
> on the subject of mapping X.500 operations onto data stored in a relational
> database.  Is it trivial, or are there interesting or difficult issues?

I can't point you to any papers or reports, but we did produce a
working prototype of just such a thing here. We mapped onto an
existing oracle relational database, so we did not get to do the
table design ourselves (which would've made things a lot easier).

Our mapping was search/read/list only (no add/remove/modify/modrdn).
The biggest challenge was coming up with a configurable and flexible
way to map from an X.500 query to an SQL query. Conceptually, it's
not that hard, but in practice we found it very difficult to produce
queries that performed well. The process was very sensitive to small
changes (for example, doing a case-insensitive as opposed to case-
sensitive search could cause a linear search of a table). If we'd
been able to tweak the table design, things would probably have
worked out better. But I still have my doubts that we could have
handled our current query load as well as we currently do.

Another problem we only scratched the surface of was mapping the
namespace we wanted to present. That's a lot of work, for what seems
like fairly little benefit. It also adds a big performance hit every
time an entry is referenced. Again, being able to design the tables
ourselves would have helped.

In summary, it was not trivial, and the problems we encountered were
difficult but not that interesting. We got something working, but
abandoned it because of performance problems. We may revisit the
problem sometime.                                         -- Tim