[plug] LDAP Design thoughts
weirdit at gmail.com
Sat May 21 15:13:10 WST 2011
On 21 May 2011 15:12, Carl Gherardi <carl.gherardi at gmail.com> wrote:
>> The first option could look like
>> Users dn
>> Payment dn's
>> The second would have payments like so:
>> 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.
When you say grow the user object, what do you mean? When I browse the
LDAP tree, it shows each payment object as a child of the user object
(not as an attribute).
So far, doing a search for all paymentObjects below the user's DN is
very nice for getting all the payments for a user.
Or are you referring to the backend needing to grow the userobject in
it's "database" (B-tree I believe).
> 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.
Using shadowExpire, we don't even need to scan the payments (unless
someone manually adds a payment without updating shadowExpire).
Really, the payments are for historical record keeping and are only
displayed when the user's details are displayed. I'm not aware of any
other uses's of the payments information.
I guess I know ether solution will work. But is there a "right" way
and a "wrong" way?
Timothy White - Somewhere in Australia
More information about the plug