Táto otázka bola položená v rôznych formách. Najbežnejšou otázkou je však: Prečo OpenLDAP neprestane používať databázu Berkeley DB a nezačne miesto nej používať systém na správu relačných databáz - relational database management system (RDBMS)? Vo všeobecností platí, že sofistikované algoritmy implementované v komerčne využívanom RDBMS by mohli OpenLDAP zrýchliť alebo inak zlepšiť a zároveň umožnia zdieľanie dát s ostatnými aplikáciami.

Stručná odpoveď je, že používanie začlenenej databázy a vlastného indexovacieho systému umožňujú programu OpenLDAP poskytovať vyšší výkon a stabilitu bez straty spoľahlivosti. OpenLDAP používa Berkeley DB čo je databázový softvér podporujúci súbežnosť a transakcie. Je to ten istý softvér, ktorý je používaný najznámejších komerčných adresárových softvéroch.

Dlhšia odpoveď môže byť takáto. Všetci neustále premýšľame o tom, čo vybrať  RDBMSy alebo adresáre. Je to ťažká voľba a neexistuje na ňu jednoduchá odpoveď.

Je lákavé si myslieť, že ak použijeme RDBMS ako systém na pozadí pre adresár, vyriešime všetky problémy. Nie je to však pravda. Je to preto, lebo dátové modely sú veľmi odlišné. Reprezentácia dát adresára pomocou relačnej databázy si vyžaduje rozdelenie dát do viacerých tabuliek.

Teraz budeme na moment rozmýšľať v osobe objektovej triedy (objectclass). To je definícia vyžadujúca atribúty typu objectclass – sn a cn a povoľuje atribúty typu  userPassword (heslo používateľa), telephoneNumber (telefónne číslo), seeAlso (pozri tiež) a description (popis). Všetky tieto atribúty umožňujú zadať viacero hodôt naraz, preto normalizácia vyžaduje, aby sme pre každý atribút pridali inú tabuľku.

Teraz budeme musieť rozhodnúť o vhodnosti príslušných kľúčov pre tieto tabuľky. Hlavný kľúč by mohol pozostávať s kombinácie DN (názvu domény) ale to sa ukazuje vo väčšine databázových implementácií neefektívne.

Veľkým problémom teraz je, že pri prístupe k dátam je potrebné jeden záznam hľadať v rôznych oblastiach disku. Pri niektorých aplikáciách to nemusí vadiť, ale v mnohých aplikáciách to znižuje výkon.

Jediné hodnoty, ktoré je možné vložiť do hlavnej tabuľky sú tie, ktoré sú jedinečné a umožňujú zadať iba jednu hodnotu. Môžme do nej dať aj nepovinné atribúty, ktoré umožňujú zadať len jednu hodnotu a ak ju používateľ nezadá použijeme miesto nej hodnotu NULL alebo niečo podobné.

No počkať, ale veď záznamy môžu mať viacero hodnôt objektových tried a môžu navzájom od seba dediť. Záznam typu objectclass s názvom organizationalPerson má teraz atribúty od osoby aj od niektorých iných záznamov a niektoré atribúty, ktoré v nich boli nepovinné sú teraz povinné.

Čo s tým? Mali by sme mať samostatné tabuľky pre každú objektovú triedu? Týmto spôsobom by osoby mali záznam v tabuľke person, a ešte jeden v tabuľke organizationalPerson, atď. Alebo by sme sa mali zbaviť tabuľky person a umiestniť všetko do druhej tabuľky?

Čo by sme ale urobil s filtrom ako napríklad (cn=*) pričom cn je atribút, ktorý sa nachádza vo veľa, veľa objektových triedach. Mali by sme prehľadávač všetky možné tabuľky či v nich nájdeme zhodu? To nie je veľmi atraktívne.

Ak takýto prípad nastane, do úvahy pripadajú možné riešenia. Jedno je že každý typ atribútu, pričom nebude záležať aký, bude mať svoju vlastnú tabuľku. Zjednodušujúci prístup, v ktorom bude DN súčasťou primárneho kľúča je extrémne nehospodárny. Vyžaduje si tabuľky, v ktorých záznamy majú jedinečný identifikátor, ktorý sa použije namiesto kľúča a hlavnú tabuľku, ktorá spája DN kľúče s identifikátormi. Tento prístup je aj tak veľmi neefektívny pri požiadavke na niekoľko typov atribútov z jedného alebo viacerých záznamov. Takáto databáza môže byť spravovaná (aj keď nemotorne) SQL aplikáciami.

Druhý prístup je vložiť celý záznam ako guľku do tabuľky zdieľajúcej všetky záznamy bez ohľadu na objektovú triedu, a ktorá bude mať aj prídavné tabuľky, ktoré budú vystupovať ako indexy prvej tabuľky. Indexové tabuľky pritom nebudú pod správou databázy ale budú plne spravované implementáciou na strane LDAP servera. Týmto sa však stanú nepoužiteľné pre SQL. Databázový systém poskytne teda len veľmi malú ak vôbec nejakú výhodu. Funkcie robustného databázového systému sú teraz úplne zbytočné. Oveľa lepšie je použiť niečo oveľa ľahšie a rýchlejšie – niečo ako Berkeley DB.

Úplne odlišný spôsob, ako sa na problematiku pozrieť je ten, že sa úplne vzdáme realizácie adresárového dátového modelu. V takom prípade, sa LDAP bude používať ako prístupový protokol k dátam, ktoré budú iba povrchne reprezentovať adresárový dátový model. Pre inštanciu by tento prístup bol iba na čítanie alebo by sa pri aktualizáciách uplatňovali obmedzenia, ako napríklad vkladanie len jednej hodnoty do tých typov atribútov, ktoré umožňujú viacero hodnôt. Nebude tiež možné pridať objektovú triedu k existujúcemu záznamu ani odstrániť už existujúcu. Obmedzenia z rozsahu povolených obmedzení (ktoré sú inde výsledkom riadenia prístupu) vedú k úplnému narušeniu dátového modelu. Napriek tomu však túto metódu môžeme využiť na poskytnutie prístupu k LDAP údajom, ktorý môžu použiť ostatné aplikácie. No nebudú pristupovať ku skutočnému "adresáru".

Existujúce komerčné  LDAP serverové implementácie, ktoré používajú relačnú databázu sú buď prvého alebo tretieho druhu. Nepoznáme žiadnu implementáciu, ktorá by používala relačnú databázu robiť neefektívne to, čo  Berkely DB robí efektívne. Pre tých, ktorí sa zaujímajú o "tretí spôsob" (Vystavenie EXISTUJÚCICH dát cez RDBMS ako LDAP strom, pričom budeme mať isté obmedzenia v porovnaní s klasickým LDAP modelom, ale umožníme spoluprácu medzi LDAP a SQL aplikáciami):

OpenLDAP obsahuje back-sql – pozadie, ktoré to umožňuje. Používa ODBC + dodatočné matainformácie o preklade LDAP požiadaviek do SQL požiadaviek v našej RDBMS schéme, poskytujúcej rôzne úrovne prístupu – od  prístupu len na čítanie po plný prístup a záleží od vás ako RDBMS a schému použijete.

Viac informácií o tomto koncepte a jeho obmedzeniach, sa môžeme dozvedieť na man stránke slapd-sql(5), alebo v časti Backends. Existuje tiež niekoľko príkladov s RDBMSmi v podpriečinkoch back-sql/rdbms_depend/*.