Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Postgre/hibernate: une base avec 2 schemas ou 2 bases avec 1 schema ?

1 réponse
Avatar
Lionel
Bonjour,

J'ai une appli web java/hibernate qui attaque une base de données postgre
8.3 contenant env 10millions de lignes par an (150Mo/dump).
Je vais devoir faire une autre base possédant exactement la meme structure
mais contenant d'autres données (volumétrie identique) et attaquer l'une ou
l'autre de ces bases selon le login de l'utilisateur.

Seule contrainte: la gestion de tous les utilisateurs doit se faire dans une
seule base.

Je vois 2 possibilités:

1) deux bases de données

Je configure 2 datasources différents pour tomcat.
J'initialise 2 sessionFactories hibernate en changeant juste le
hibernate.connection.datasource
et je choisis le bon en fonction du login à chaque requete http.
avantages: impossible de se tromper de schema lorsque l'on lance une
requete, dump/restore d'une seule base à la fois, rien à faire si un jour il
fallait séparer les 2 bases (une simple recopie des utilisateurs)
inconvenient: 2 bases à gérer, obligation de faire une verrue pour la
gestion des utilisateurs car le 2e datasource verra une table d'utilisateurs
vide.

2) une base de données avec 2 schemas

Je configure un seul datasource pour tomcat.
J'initialise 2 sessionFactories hibernate en changeant juste le
hibernate.default_schema et je choisis le bon en fonction du login à chaque
requete http.
avantage: un seul pool de connexion, une seule base à gérer
(dump/restore,...), il me suffit de forcer le schema public sur la table des
utilisateurs pour que leur gestion soit transparente depuis l'appli
inconvénient: perf des dump/restore vu que je suis obligé de travailler sur
les 2 bases en meme temps.


D'après vous, quelle est la meilleure solution tant d'un point de vue SGBD
que java ?

Suivi positionné sur fcas.

1 réponse

Avatar
TestMan
Bonjour,

J'ai une appli web java/hibernate qui attaque une base de données postgre
8.3 contenant env 10millions de lignes par an (150Mo/dump).
Je vais devoir faire une autre base possédant exactement la meme structure
mais contenant d'autres données (volumétrie identique) et attaquer l'une ou
l'autre de ces bases selon le login de l'utilisateur.

Seule contrainte: la gestion de tous les utilisateurs doit se faire dans une
seule base.

Je vois 2 possibilités:

1) deux bases de données

Je configure 2 datasources différents pour tomcat.
J'initialise 2 sessionFactories hibernate en changeant juste le
hibernate.connection.datasource
et je choisis le bon en fonction du login à chaque requete http.
avantages: impossible de se tromper de schema lorsque l'on lance une
requete, dump/restore d'une seule base à la fois, rien à faire si un jour il
fallait séparer les 2 bases (une simple recopie des utilisateurs)
inconvenient: 2 bases à gérer, obligation de faire une verrue pour la
gestion des utilisateurs car le 2e datasource verra une table d'utilisateurs
vide.

2) une base de données avec 2 schemas

Je configure un seul datasource pour tomcat.
J'initialise 2 sessionFactories hibernate en changeant juste le
hibernate.default_schema et je choisis le bon en fonction du login à chaque
requete http.
avantage: un seul pool de connexion, une seule base à gérer
(dump/restore,...), il me suffit de forcer le schema public sur la table des
utilisateurs pour que leur gestion soit transparente depuis l'appli
inconvénient: perf des dump/restore vu que je suis obligé de travailler sur
les 2 bases en meme temps.


D'après vous, quelle est la meilleure solution tant d'un point de vue SGBD
que java ?

Suivi positionné sur fcas.


Bonjour,

Vous avez deux bases séparées avec un même schéma, c'est un fait. La
complexité perceptible vient du fonctionnel que vous souhaitez y
accoler. En clair, une est maître, et l'autre doit se comporter comme
une sorte d'archive/vue.

Personnellement, je pencherait donc plus pour la solution 1.

Si la fonctionnalité de connexion à une base à partir de l'identifiant
se borne à deux bases in fine, alors essayez de créer simplement deux
entity manager se connectant vers deux datasource (se connectant chacun
à la base leur base).

Ne vous restera plus par code qu'à utiliser l'EntityManager qui va bien
en fonction du fonctionnel escompté.

Avantage : contrôle simple du fonctionnel, transactionnel clairement
séparées, contrôlé fin des performances de chaque base.
Incovénient : modification du code

Vite vu car dans le cas 2, vous aurriez de toute façon du code à
modifier ;-)

PS: rétablit sur fclj , cf. hibernate ;-)

A+
TM