Postgre/hibernate: une base avec 2 schemas ou 2 bases avec 1 schema ?
1 réponse
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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
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
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 ;-)
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 ;-)