views:

49

answers:

1

Hello,

I have a OpenLDAP Database and it holds some project objects that look like

dn: cn=Proj1,ou=Project,ou=ua,dc=org
cn: Proj1
objectClass: top
objectClass: posixGroup
member: 001ag
member: 002ag
System: ABEL
System: PCx
Budget: ABEL:1000000:0.3
Budget: PCx:300000:0.3

One can see that the Budget attribute is a ":"-separated string, where the first part holds the name of the system the budget is for, the second part holds some budget (which may change every month) and the last entry is a conversion factor for the budget of that system.

Seeing this, I thought this is bad database design, since attribute values should always be atomic. But how can I improve that in LDAP, so that I can do a direct ldapsearch or a direct ldapmodify of the budget of System "ABEL" instead of writing a script, that will have to parse and split the ":"-separated string?

+1  A: 

It's a good idea to break things up into groups as much as you can until you get down to individually distinguishable elements, which in your case would be Systems. As you've realized, having the smallest element in the database be Project is a problem when you have more than one System.

I would put a sub-group for each project inside the main Project group, aka:

- ou=Project
   + ou=proj1
   + ou=proj2
   + ou=proj3

Inside each of these you can have an object for "member" or "System", whichever is the more distinguishable attribute. For the sake of an example I'll assume "member" is the better choice. Following this idea, inside each sub-group you would have objects like this:

 - ou=Project
    - ou=proj1
       - dn: cn=sys1,ou=proj1,ou=Project,ou=ua,dc=org
         cn: sys1
         objectClass: top
         objectClass: posixGroup
         member: 001ag
         System: ABEL
         Budget: 1000000:0.3

       - dn: cn=sys2,ou=proj1,ou=Project,ou=ua,dc=org
         cn: sys2
         objectClass: top
         objectClass: posixGroup
         member: 002ag
         System: PCx
         Budget: 300000:0.3
   + proj2
   + proj3

Now each system is its own entity, but the project is still grouped together as a whole.

elmugrat
+1 Good point of view. =)
Will Marcouiller
Thanks! Always good to know someone agrees haha
elmugrat
For my case "System" is the more distinguishable attribute, since every system is supposed to have all members. But I think I get what you mean and so I will use sub-groups with cn=ABEL,ou=proj1,ou=Project,ou=ua,dc=org, cn=PCx,ou=proj2,ou=Project,ou=ua,dc=org. Thank you for your answer.
asmaier
Yes, that's exactly what I meant. Glad I could help and good luck!
elmugrat