Re: VLV indices and multi-value attributes

[Ed Reed <ED_REED@novell.com>]

The typical administrative or white pages applications -

Display all users sorted by their (a) names or nick names, (b) phone numbers of various types.
Display all servers sorted by (a) their network addresses, (b) their various DNS names

The common name, phone number, and network address fields are all likely to be multi-valued.  The objective of such a sorted selection is not to get a list of users that only includes the "smallest" of their phone numbers, or the "least" of their common name values, but all their phone numbers (so you can perform a lookup, for instance, via callerID, or so you'll see both William Faulkner and Bill Faulkner in your search results without having to algorithmically derive Bill from William, or worse yet, William from Bill (Bill woud be "least").

Similarly, an administrator may very well want to see their environment as DNS projects it, with all the CNAME fields expanded, so that all the names for an address appear in the list, and vice versa for another listing,  all the addresses for a name appear...

Very common report-oriented, and administrative browser-oriented, queries that we see requests and uses for every day.

In the messaging world, retrieving the vlv list of all members of all mail distribution lists, sorted by member names would be useful, don't you think?  Doesn't work if you only take the "least" value of each distribution list as that list's value...

Ed
>>> David Boreham <dboreham@netscape.com> 10/05/1998 10:30:56 >>>
Ed Reed wrote:

> Projecting that table into a list where the selection criteria was on entryID and attributeID DOES get you multiple values for each entryID, if indeed there are multiple values stored ... and isn't that the behavior "reasonable" consumers would expect?

Hmm. Sounds interesting, but I'm not sure what problem you're trying to solve.
Can you give an example ?




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