Comment faire son choix entre NoSQL et une base orientée objet ?

Bonjour,

Je souhaite débuter un nouveau projet en Java, et j'aimerais à cette occasion changer de système de persistance pour en avoir un répliquant précisément la structure des données que je veux sérialiser.
Il y en a deux qui m'apparaissent : NoSql et les bases orientées objet.

1) Installation, administration et incorporation
Sont-elles l'une et l'autre d'un abord facile pour ce qui est de l'intendance du moteur qui les gère ?
Faciles à installer, à administrer ? Ou est-ce la croix et la bannière pour seulement les faire démarrer ?

S'intègrent-elles très aisément à Java par le biais d'API :
a) Dédiées, à l'interface spécifique ?

b) ou au contraire, savent-elles s'intégrer à du JPA :
- pour les ordres CRUD simples ?
- par du JPQL ? Là, je soupçonne que ça passerait avec une base de données objet, mais un NoSQL, qu'en penserait t-il ?


2) Évolution de la structure des données existantes
C'est le problème le plus important à mes yeux.

Je vais sérialiser des objets A {variables membres : C, D et E} héritant de B {variable membre : F}. Un jour mon projet bouge et :
- B hérite maintenant de G (héritage supplémentaire).
Tous les objets de la base ayant hérité de B pourront-ils impactés, si je le désire, ou seulement celui que je persiste individuellement ?

- F change de type dans B (changement de type de variable dans une classe héritée).
- A perd et gagne une variable membre.

Ces opérations se font-elles ou sont-elles très difficiles à accomplir ?


Je vous remercie pour vos avis.

Il y a longtemps que les bases de données objet ont rendu l'âme et ceci par darwinisme :
1) pose de contraintes difficile à très complexes, rendant le système globalement lent
2) indexation des objets impossible sauf pour des objets très simples et bien connus (XML, spatial...) ou atomiques => lenteurs inacceptables

En revanche, les SGBD Relationnels ont intégrés de l'objet comme données annexes. Par exemple Oracle avec du JAVA et SQL Server avec du .net (SQL CLR). De même, ces SGBD proposent des types objets préfabriqués comme XML ou le spatial, parfaitement indexables et contraignables.

A noter : l'absence de contraintes rend globalement le système plus lent :
1) il faut souvent nettoyer dynamiquement les données avant d'obtenir des résultats sains
2) certains bon SGBDR sont capable d'optimisations sémantiques, si l'on pose les bonnes contraintes.

Pour ce qui est du NoSQL, l'adaptation à l'objet est encore pire, sauf à passer pas du JSON.

A +