RE: VLV indices and multi-value attributes

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

Yes - having a realional model under the X.500/LDAP object model can
offer some interesting options. eg we can relate aliased  enries to the
alias, and other, etc. 
However, X.500 and LDAP deals with the object model so any semantic of
tables and columns on the access and interserver interfaces just means
that the client is now managing the "database" and its table/col/row
relationships.

regards alan

> -----Original Message-----
> From:	dboreham@netscape.com [SMTP:dboreham@netscape.com]
> Sent:	Tuesday, 20 October 1998 2:56
> To:	Ed Reed
> Cc:	merrells@netscape.com; JIMSE@novell.com;
> osidirectory@az05.bull.com; d.w.chadwick@iti.salford.ac.uk;
> ietf-ldapext@netscape.com
> Subject:	Re: VLV indices and multi-value attributes
> 
> Ed Reed wrote:
> 
> > In fact, if you simply follow the canonical syntax for relational
> SELECT operations, you see
> >
> > SELECT columns (attributes, in LDAP)
> > FROM tables (classes in LDAP)
> > WHERE selection criteria (search filter in LDAP)
> > ORDER BY results ordering criteria (your proposed sort control in
> LDAP)
> 
> Trouble is, the Directory isn't a relational database.
> Different information model.
> Many subtle consequences result.
> 
> Relational access to the underlying data stored in
> a Directory Service is an intersesting facility, but
> I suspect it's a quite different animal to some extensions
> to LDAP.
> 
>