Certo è difficile trovare un punto di equilibro, soprattutto in progetti in cui il disegno del DB è delegato ad un team che spesso, per formazione, sono esclusivamente orientate al modello relazionale puro, mentre il disegno delle classi e, più in generale, di come l’applicazione deve realizzare tecnicamente quanto espresso nella specifica è gestito da programmatori che pensano esclusivamente ad oggetti.
Una possibile soluzione è quella proposta da Zuck: utilizzare un DB ad oggetti come db4o.

Come ho detto si tratta di una possibile soluzione, almeno sulla carta. Infatti, specialmente in grandi progetti o in ambiti dove gli skill sono ben definiti e valutati, ricrearli da zero, su di un prodotto nuovo e poco conosciuto potrebbe rivelarsi molto meno fattibile del previsto.
Una via più semplice, specialmente per chi programma in Java, è rappresentata da Oracle TopLink:

Oracle TopLink, industry leading Java object-to-relational persistence architecture, provides a highly flexible and productive mechanism for storing Java objects and Enterprise Java Beans (EJBs) in relational databases and for converting between Java Objects and XML documents (JAXB). TopLink offers developers excellent performance and choice, working with any database, any application server, any development toolset and process, and any J2EE architecture.

Trotterellando anche un po’ su Google ho ritrovato una vecchia conoscenza mia e di Zuck (JavaConference 2003?), Cachè, un DB ad oggetti commerciale le cui performance sono dichiarate elevatissime. Legato a Cachè ho trovato anche un interessante documento dall’illuminante titolo “Oscillating Between Objects and Relational: The Impedance Mismatch”.

Spero a breve di far seguire una breve recensione.