---

   slapd-sql    ( 5 )

---

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.