On 11/2/06, Alex Karasulu <aok123@be= llsouth.net> wrote:

Ersin Er wrote:
<snip/>> How can we map Attributes to SQL model= ?

There are probably a few ways to do this but some will be much fas= ter
however the faster it is the uglier it will be.

One way is to= have one big table with the following columns:

1). ENTRY (BLOB)
2). NDN (VARCHAR)
3). UPDN (VARCHAR)
4). = ID (INTEGER)

Well, from a RDBMS point of view, I think= that a correct structure will be something like :
A first table, = ENTRY_T, with those columns :

DN : varchar (but may be an id, which will refer to another table)<= br>ATTR : attribute name, varchar

and an ATTRIBUTES_T table :
DN = : varchar
ATTR : varchar
VALUE : blob

The idea is that yoiu wi= ll set index on those table, so you don't need anymore to declare NDN.
For instance, if you want to get all attribute values for an entry, the= n the request will looks like :
select DN, ATTR, VALUES from ATTRIBUTES_= T where DN =3D %dn%

(%dn% stand for the DN you are looking for)

Now, if you want all the entries which cn =3D ACME, the request will be= :

select DN, ATTR, VALUES from ATTRIBUTES_T where DN in (select DN = from ATTRIBUTES_T where ATTR =3D 'cn' and VALUE =3D 'ACME')

Just set= the correct index to have good performances !

(this is just a first approach, we need to improve it a _lot_)
<= br>I have put some thought related to backend organization here : http://docs.safehaus= .org/display/APACHEDS/Backend
but it needs to be further a lot !

You can lookup entries that are bl= obs this way by normalized (NDN) and
user provided distinguished names (UPDN) as well as by ID.

If yo= u want to index a specific attribute use some DDL to add a new
COLUMN to= this table.  That column should be the name of the attribute
= being (LDAP not DB) indexed.  Do a full table scan the first time= and
populate this new "index" COLUMN with the values of the attri= bute.

Handling queries now is not that complex.  Basically= you need to
determine which attributes you have indices on and which yo= u don't.
Then do a query to select and narrow down the rows that you'll have to<= br>resusitate the entry from the blob from.

You might need another t= able for an existance index too.  The EXISTANCE
table might ha= ve a ATTRIBUTE column, and ID column.  If a record exists
in this table for an attribute your blobed entry then has a value forthis attribute.

Should we hold Attribute
> Values in blobs?<= br>
You will need to hold the entry in a blob.

Well, you have two options : varchar for simple and limited entries (but va= rchar can't be larger than, say, 256 chars, which may become a problem, or = blobs, for binary elements or big chars. That's a pitty because blobs sucks= when you want to set index on them.

>= ; Can we leverage the power of SQL SELECT for LDAP search operations?
Sure. You just need to know how to build the WHERE clause of SQL= using
this simple schema.

> How much of the partition code in= ADS can be used for this task?

Not much.

Yes, = this will be really one of our biggest problem.=20

Ale= x