Il primo personale lavoro di programmazione remunerato risale ai tempi del dBIII/dBXL della Ashton-Tate. Questo era un DBMS relazionale con un suo linguaggio di programmazione interpretato, e posso quindi dire di essere nato come sviluppatore quando i database relazionali si erano già affermati. La loro nascita risale al trattato del 1970, Relational Model of Data for Large Shared Data Banks di E. F. Codd. Precedentemente si lavorava con i database gerarchici e i reticolari.

I database gerarchici sono stati sviluppati negli anni '60 e sono stati sostituiti da quelli relazionali a partire dagli anni 80. Di questa tipologia di database si accenna in molti testi relativi alle basi di dati, sempre in brevi introduzioni storiche, da una parte suggerendo la loro vetustà, ma dall'altra informando che vengono utilizzati ancora ai giorni nostri. Il database gerarchico più conosciuto è quello sottostante a LDAP (Lightweight Directory Access Protocol). I dati vengono organizzati in insiemi che si legano tra loro tramite la sola relazione di "possesso"; un insieme padre può possedere altri insiemi, figli; ma un insieme figlio può appartenere solo ad un unico altro insieme, il padre.

Il modello risultante è la classica struttura ad albero. LDAP è in realtà un protocollo che permette di accedere a dei servizi che hanno una base informativa. A differenza del modello relazionale, strutturato in righe e colonne, questa base informativa memorizza i dati come una coppia nome-attributo, valore-attributo. Punto di forza è la flessibilità, dato che si possono aggiungere attributi, senza alcun impatto sulle procedure di accesso alla base dati e sulla velocità di lettura di informazioni gerarchiche, che nei database relazionali non è propriamente performante, a meno di sintassi specifiche del RDBMS come visto in Query gerarchiche in Oracle. Altro esempio di database informativo gerarchico sono i file XML, che probabilmente sono il modello più evidente di struttura dati diversa da quella relazionale, e anche il più riuscito e sfruttato.

Un altro caso di database gerarchico è capitato nella mia normale attività lavorativa ed è quello che ha ispirato il presente articolo. Si tratta del database P4 dell'applicazione HP Open View Service Center, un prodotto di Service Management, che dovrebbe rispettare le best practices ITIL. L'utilizzo del database gerarchico in questo caso, non sembra dettato da una particolare strutturazione delle informazioni, ma probabilmente da una scelta di compatibilità. Caratteristiche di questa soluzione sono una ridondanza delle informazioni che è bilanciata da una discreta velocità.

Il database di default dell'applicazione risiede su diversi file in una directory DATA, che può essere semplicemente copiata per fare ad esempio un backup, oppure per portare il database da un server ad un altro. La consultazione di un database del genere, invece, risulta notevolmente più complessa ed elaborata. Il database relazionale è senza dubbio il miglior modello da utilizzare nella maggior parte degli scenari di dati. Esistono, però, ancora oggi delle particolari necessità informative alle quali è più conveniente applicare modelli che si adattino meglio.