Re: account balances

[Derek Simkowiak <dereks@itsite.com>]

> of the slaves. I then take out another 999,999 Euros. I've arranged for
> that slave to crash too ...

	The problem with this scenario is that it applies to any database;
whether it be a filesystem, SQL, LDAP, whatever.  It does not explain why
LDAP is weaker for account balances than, say, SQL.

	My understanding is that LDAP has atomic transactions just like
some SQL databases do.  To my [limited] knowledge, neither MySQL nor
Postgres offer atomic transactions across a group of replicated servers. \

> People who look after other peoples' money just do not put any account
> details in ldap directory servers.

	This is in my experience also, but the only reason I have ever
heard of is performance.  (Normally account balances need to be updated
quite frequently across a given population of users, and there can be
various recurring complicated searches that can be optimized by using
stored procedures in the SQL server.)

	The original poster said he mostly needed to read the balance, not
modify it (very frequently).  This would be exactly like an "account_paid"
attribute that an ISP might use in its LDAP database of custer usernames.
LDAP-aware client apps use this kind of attribute to decide, for example,
if a customer is allowed to receive email, or if a customer is allowed to
get access to their files, or login to their account.

	I don't think there is anything unreasonable in what the poster is
proposing.  Personally, I'd redesign the database to not store an actual
account balance (which is rather sensitive information), but instead a
boolean value saying whether or not the account balance is
"acceptable"/"paid up"/"whithin minimum requirements".  That is, divide
your business rules such that the LDAP server only needs a boolean
attribute, instead of an integer.


--Derek