[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: VLV indices and multi-value attributes



hmmmmm....lest there be any misunderstanding...

my comments were not to suggest that we either replace nor undergird
LDAP with relational data models.

But, we need to be able to relate LDAP data models in a rational fashion
to the relational models being taught in schools, and 

Where appropriate, steal good ideas that suggest fundamental patterns
of usage, and apply them to our own efforts.  Here I mean the segmentation
of data access into data identification, selection critera, and ordering
preferences, as a beginning.

Ed

----------------------
Ed Reed, Technologist
Novell, Inc.
+1 801 861-3320

>>> Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> 10/25/1998 14:38:21 >>>
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.
> 
>