[plug] LDAP Design thoughts

[Carl Gherardi]

> The first option could look like
>
> Users dn
> cn=user,ou=Users,dc=plug,dc=org,dc=au
>
> Payment dn's
> paymentid=34,cn=user,ou=Users,dc=plug,dc=org,dc=au
> paymentid=121,cn=user,ou=Users,dc=plug,dc=org,dc=au
> paymentid=422,cn=user,ou=Users,dc=plug,dc=org,dc=au
>
> The second would have payments like so:
> paymentid=34,ou=Payments,dc=plug,dc=org,dc=au
> paymentid=121,ou=Payments,dc=plug,dc=org,dc=au
> paymentid=422,ou=Payments,dc=plug,dc=org,dc=au
>
> This second way would require another attribute (most likely in each
> payment) referring back the user who's payments they are.
>
> Is there any reason for one over the other? Efficiency? Structural organisation?

Depends on what you anticipate your usage to be, and if you have
another (preferred) record for payments.

My LDAP is a bit rusty, so do trat this as gospel.

If you need to be able to audit all payments indefinitely then option
2 is best as you will continually need to grow the user object for
each payment in option 1, or do ugly things like
'paymentid=34|121|422' as the member renews.

If all you care about is scanning the user list to find out if the
membership is current or within a date range so you can email
reminders, or query financial members, then option 1 is easiest.

Carl G