Re: VLV indices and multi-value attributes

[Ed Reed <ED_REED@novell.com>]

Granted.  But relational IS the metaphore that is taught, these days, in 
computer science schools, almost to the exclusion of hierarchical or
network models.  And you have to admit that the SELECT clause
construct presents a useful breakdown of the relevant parameters, and
even suggests, reasonably, I think, a way of breaking down the problem...
identify the useful data from the data sources on the basis of some
inclusion/exclusion criteria, then sort the results and return them to the 
requestor.  It's that separation of inclusion/exclusion criteria from the
desired ordering that I think can inform us about "intuitive" partitioning
of arguments and operations, and that suggests that the sorting control
is usefully separate from the selection criteria, or from the cursor management,
for that matter (vlv controls).  It leads me to believe that a sort control
that specifies collation sequence for the return set and a
cursor (paged results / vlv) control providing programs with data positioning
in the return set should be separate and not munged together (an undesireable
linking of two separate functions).

And, yes, the issue of multiply valued attributes is not something which is
dealt with generally in relational models, except through dot products and
equi-joins, but those are merely the mechanism of the relational calculus
for handling the data we construct and use.  We don't have to adopt
a relational model for the directory, but neither need we ignore the
work done there as we consider how to surface directory content 
in useful ways for developers and consumers.

Best regards,
Ed

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

>>> David Boreham <dboreham@netscape.com> 10/19/1998 10:56:10 >>>
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.