серверная часть SQL для slapd (SQL backend to slapd)
COMMON TECHNIQUES
First of all, let's recall that among other major differences to
the complete LDAP data model, the above illustrated concept does
not directly support such features as multiple objectclasses per
entry, and referrals. Fortunately, they are easy to adopt in
this scheme. The SQL backend requires that one more table is
added to the schema: ldap_entry_objectclasses(entry_id,oc_name).
That table contains any number of objectclass names that
corresponding entries will possess, in addition to that mentioned
in mapping. The SQL backend automatically adds attribute mapping
for the "objectclass" attribute to each objectclass mapping that
loads values from this table. So, you may, for instance, have a
mapping for inetOrgPerson, and use it for queries for "person"
objectclass...
Referrals used to be implemented in a loose manner by adding an
extra table that allowed any entry to host a "ref" attribute,
along with a "referral" extra objectClass in table
ldap_entry_objclasses. In the current implementation, referrals
are treated like any other user-defined schema, since "referral"
is a structural objectclass. The suggested practice is to define
a "referral" entry in ldap_oc_mappings, holding a naming
attribute, e.g. "ou" or "cn", a "ref" attribute, containing the
url; in case multiple referrals per entry are needed, a separate
table for urls can be created, where urls are mapped to the
respective entries. The use of the naming attribute usually
requires to add an "extensibleObject" value to
ldap_entry_objclasses.
