db/schemas best practice

[Michael Engelhart <mengelhart@katahdinsoftware.com>]

Hello -

In the FAQ-omatic, there's a post regarding having multiple databases 
with the following quote:
"SLAPD can be configured to support multiple databases and each 
database can support multiple suffixes.  The multiple databases each 
with a single suffix approach is preferred over the single database 
with multiple suffix approach. "

I am developing something which stores contact data for multiple 
'clients' (i.e., discrete businesses).

My theory based on the FAQ response is to partition off each client,  I 
could create a separate bdb backend config in slapd.conf and each time 
a client is added, add this and restart the server.  Is this a 
reasonable approach?
There is the headache of manually editing slapd.conf each time a client 
is created but besides that is there any thing "wrong" with handling it 
this way.

My 2 questions assuming this is  OK are:

1) How many backends can slapd deal with before needing to move to a 
new process or server (none of these clients will have more than 
probably 10,000 entries).

2) Some of the clients have custom attributes they want to have in 
there like for example and auto dealer may want to have a vehicleMake, 
vehicleModel and vehicleYear attributes so they can have that 
information associated with their customers entry.   What I have 
currently is a schema that is shared by these backends and this seems 
to work fine.  But if/when a new client comes on and I need to add an 
attribute, does this "break" existing clients data?  The existing 
clients wouldn't be accessing or using these new attributes.   Or do I 
have to dump and restore every backend when I make a change like that.  
 Would a better approach be to have a schema for each client that needs 
new entries.   The schema attributes are "generally" industry related 
so if I have 10 auto dealers, they'll all basically have the same 
requirements so they can be shared to some extent.


Any advice is appreciated.

Michael