I don't want to make this longer than necessary, but if you have a table favourite_drink
person_id, drink
containing
'ando' 'coke' 'ando' 'beer'
and you
"delete from favourite_drink where person_id='ando' and drink='coke';"
and
"insert into favourite_drink (person_id,drink) values ('ando','wine');"
I'm pretty confident 'wine' will not come before 'beer', even if 'wine' is what I really prefer.
In this sense, I think LDAP was designed to be almost as dumb as most applications (and application developers) but not dumber. So, values with the very same importance go into sets, and values with special importance go into specific attributes, possibly with SINGLE-VALUE constraint if appropriate, as I explained in my previous message.
As a general rule, don't ask software to do what can be better done by yourself, and viceversa :)
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Thanks for this short but clear information which is as long as needed! The difference here between relational database and LDAP is we cannot design LDAP so we begin to expect more from LDAP, e.g. in case of favorite drink order, a table can be designed more complex to preserve order, but LDAP structure cannot be designed. However I think this is again my mistake, because LDAP structure CAN be "designed" by changing value format. I can "design" the client must not directly store the name of drinks, it should store the drinks in a format a number followed by the drink. e.g.
favoriteDrink: 1 coke favoriteDrink: 2 beer
So here I used to think "usuall values in db can be presented to user as-is", with this new format, the client remove the leading digit after sorted values and present the result to users. The change of table structure in RDBMS map to the change of value format in LDAP, this is the part that people don't get fast and easily.
But having gone this far, my solution is already very close to that of Chu, so I get the idea of Chu's design now. I am very happy and thankful that openldap already implemented Chu's solution so that I have less to do on the client (the client code for sorting and re-calculating index numbers of values are no longer needed). What easily frastrates administrator and developers is if some problems don't have a solution at all, e.g. in my case companyRepresentative order is vital and total number is unknown, the db by itself provided no solution and you cannot re-design the database! I am glad I am wrong, there is a solution. Change value format needs to update client, but it's better than I can do nothing about it.
And thanks for your time!
在 2007-08-14二的 22:28 +0200,Pierangelo Masarati写道:
openldap-software@openldap.org