[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Producing a web directory with LDAP

At 10:21 -0600 29/1/03, Ryan Gallagher wrote: 
Quoting Adam de Zoete <AtoZ@dnet.co.uk>:

 Hi,

 Firstly let me say that i'm new to this list and new to LDAP. However
 i'm looking for a flat file solution (or non-RDBMS) to produce a web
 directory and am prepared to put in some learning curve in order to
 be in an appropriate format.


Cool.  We are attempting a re-design based around much the same concept.

 Firstly, could I be looking in the right place with LDAP? Would you
 have any other suggestions to build something like this?....


I don't think LDAP is commonly thought of for this purpose, but it is by
no means outside the scope of possibility.  We are doing it here because,
our company changes it's scope on a daily basis, and ldap schemas are far
more flexible and _should_ allow us to integrate new data without spending
as much time re-working the existing parts of the schema.  We also have the
need to replicate localized 'read-only' copies of our data to remote
locations.


Ryan,

Can I have multiple schemas all interlinked? I imagining a schema is a hierarchical tree structure, where the root can be planted wherever you want?!? So I could have different schema for 'area within directory' and 'entry contents' with possibly an SQL db handling the relational data (discussed in other message).

'area within directory'
AREAS > UNITED KINGDOM > ECOMMERCE > SUPERMARKETS

'entry contents'
Title:
Description:
Keywords:
URL:
Display:
Hits:

This way I could put the content of one schema inside another. i.e. 'entry contents' could be placed anywhere within 'area of directory'. I suppose i'm asking if schema are relational?

> I have some relational data that is based on the directory. In some 
 articles online it claims that LDAP can't handle relational data, or
 that it's simply not tailored for updating data on the fly. Can you
 suggest ways of handling various relational bits of data, for one
 example, hit-counters? Or any data that needs to be updated
 regularly? (None of the data needs to be accurate to the second or is
 time sensitive)


Ahh, there you go.  If 'time' accuracy is a allowable sacrifice, you are on
the right path.  It is not entirely true that LDAP doesn't handle relational
data.  Using aliases and objectclasses you can acomplish _MOST_ functionality
that you would expect from a full relational database.  The main difference
is you have to 're-train' yourself to think of your data (and schema) in a
heirarchical manner.  Most problems will have a viable solution in both
relational and heirarchical thought.

To me I think it seems easier to think of data as being embeded within something else. Are you saying that it's hierarchical like OOP methods?

> The content should be more than a few million entries and I need fast
and flexible multiple field searching. 

LDAP can handle this load, provided the 'write' events don't slow you down.
LDAP searches can be blazingly fast when you set up your indexes correctly.
But, peforming writes requires these indexes to be updated.  Another benefit
here is that you can EASILY chop off whole sub-trees and put them on dedicated
servers without having to alter queries.  This allows for quite a bit of room
to grow.

That's my worry. I will have a certain amount of write events. Is LDAP multi-threaded? Can it be performing write events while performing searches?

I'm slightly worried that it's going to be too slow writing. If this was the case could I chop off the write-to subtree and host it individually?

> Can anyone suggest whether LDAP is firstly capable of the above and 
 secondly the the correct format for holding/searching such
 information in such quantity?

Capable, yes i'm pretty sure. Correct, that is harder to say for certain. 

Do you know of any other un-relational db that could write better?

 > Can it be easily integrated into other networks/systems?

Alot of things talk to ldap.  But if you have to customize your schema too
much away from RFC objectclasses and attributes, you will break some of
this built in interoperability.  Certain clients only are "aware" of certain
types of LDAP data, such as "contact information" etc.

What is your suggestion for the ideal middle-ware for use with LDAP?

Not sure what you mean by middle-ware. GUI administration tool? Web interface? 

A scripting environment, something like PHP, ASP, PERL, etc.

Many thanks,

Adam

--
// Adam de Zoete
\\ AtoZ@dnet.co.uk