[Date Prev][Date Next]
Re: How to do statistics in ldap?
> Do I use ldap in a wrong way if I want to do some statistics on the data in it.
> Just as finding out how many people live in CA or who is the oldest live in CA.
It's not "wrong" but you would have to write your own tools or scripts
to perform the queries you are talking about, and that may the simplest
answer for your situation.
If you already have an established LDAP database, then you might want
to consider converting it to a relational model for the purpose of doing
queries, especially if there are a lot of them and they are complex
(because SQL could do what you need). Of course, then you have the problem
of doing the conversion.
If you do not have an established LDAP database, then what you are wanting
to do with your database better fits what relational databases do well,
and you should go with that.
It is not uncommon that people on this list ask for suggestions on
how to keep an LDAP and relational database in sync with each other
(one suggestion being to modify slurpd to update the relational database).
Sometimes the LDAP database is the master, and other times it's the
relational database that is the master. So maintaining both on an
ongoing basis is something you may also want to consider.
One final comment is that LDAP, for counting purposes, is going to be
slower (probably a lot slower) than relational database. This is because
even while you can get the filter right, each individual record has to
be sent to the client to be counted, whereas a relational database will
do the counting inside the relational engine, and never incur the expense
of all that network traffic to the client. So if your database is large,
or you are going to be doing this a lot and speedy results are important
to you, then either using a relational database instead of, or as a slave,
to your LDAP database might be a good idea.