qazmlp a écrit :
dn:productID=15+productID=16+productID=17+productID=18+productID=19+productID=>20+productID=21+productID=22,
<remainingPartsOfDN>
colour: White
size: small
<other attribute values>
To make it optimal, I can also mention only the min and max values in the
RDN part and then include all the values in a range as part of the
attribute-value definition.
E.g.
dn:productID=15+productID=22,<remainingPartsOfDN>
productID:15
productID:16
....
productID:22
colour: White
size: small
<other attribute values>
Hmmm... Not usre that including the range in the DN will bring any
improvement, unless you want to determinate the man and max with the DN,
but then, you will have to manipulate the returned DN string to get
those values. IMO, it would be simpler to add those two values as
attributes.
This approach also helps in directly finding out the min and max values of
the range where the given attribute belongs to.
As soon as you have found your entry with the productId, if you also ask
for min and max attributes, you will get them.
my requirement can be easily fulfilled with the multi-valued RDN
attribute.
Sure, but I warn you that it will be heavy and not really performant.
Is that really the case? My understanding is that if we keep the values as
part of the RDN(and not as a non-RDN-multi-valued as shown in your
approach) attribute, then the search will be faster.
Every value in a RDN must also be part of the entry. as you may have a
lot of combinaisons for a multivalued RDN ("productId=15+productId=22"
is equivalent to "productId=22+productId=15"), that means the search
will have to deal with one more ordering before looking for the value :
ordering the rdn elements first (using a String ordering rule) and then,
searching for the value into this list. Of course, this is a blind
guess, but as Ldap does not say anything about the RDNs elements
ordering, you have to assume that the server will implement something
like that. DNs can be seen as Strings or as a composition of internal
structures (AttributeTypeAndValues), but in both cases, things get
complicated.
I mean, it's up to the developpers of your target ldap server to make it
fast or not, but you must consider that DN is considered as a key to
find an entry, so keep it the simplest possible.
In general, the search for a key/RDN is expected to be faster than the
search for a non-key/non-RDN attribute, for LDAP/oracle. Isn't it?
I don't know how Oracle Ldap server is implemented at all , so I can't
tell in this very specific case, but I can guarantee that a search for a
value of an indexed attribute will be faster than anything else : the
index will just associate the value directly to the entry, so you will
get the result directly. And remember that every RDN element is a
attribute, so will be found using the very same algorithm, plus some
other operations, thus it can't be faster.
Of course, you will have to set an index on this attributes, otherwise
performance will be in favor of the DN approach.
Emmanuel
---
You are currently subscribed to [email protected] as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
---
You are currently subscribed to [email protected] as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
