Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Il ne me semble pas avoir trouvé de discussion sur ce sujet.
J'ai une problématique simple sur une application :
- Une DB "mère" dans laquelle se retrouve des infos "globales"
- Une DB par client. Chaque DB client est identique.
Ma question est donc simple. D'un point de vue performance vaut-il mieux une DB avec un schema public par client, ou une seule DB avec un schema par client ?
D'un point de vue montée en charge des données sur un schema, quel serait l'impact sur les autres schema puisqu'ils seraient dans la même DB ?
Après plusieurs recherches sur internet, ça reste assez vague... Une idée globale semble sortir tout de même, la méthode multiple DB est "ancienne", alors que la multiple schema est "moderne".
Mais rarement de discussion sur les performances.
Merci par avance,
Hors ligne
Avez-vous besoin de faire des requêtes travaillant sur les tables de différents clients ? par exemple pour du reporting ou des stats ? si oui, multi schémas pour disposer des jointures inter schémas. Si non, peu importe.
Du coup, je dirais bien de tout coller dans la même base : la base mère et chaque base client.
Guillaume.
Hors ligne
Oui la communication inter bases n'est pas encore très souple, malgré l'arrivée de postgres_fdw (qui est bien utile quand même).
D'un point de vue application / développement, l'inter schémas est le plus simple à maintenir. L'interrogation reste sur les performances, mais à priori en cherchant pas mal d'infos sur le net, pas grand impact avant plusieurs go par schéma.
Hors ligne
Bonjour,
J'ai déjà été confronté à ce genre de problématique et nous avons choisi de partir sur 1 base + plusieurs schémas. Avec les bons droits et une bonne gestion des rôles vous ne devriez pas avoir de problèmes.
Si vous partez sur plusieurs bases vous pouvez aussi utiliser des dblink (extension dblink à installer) mais les performances seront toujours moins bonnes que dans le cas 1 base + plusieurs schémas. Notamment si vous faites des requêtes inter schémas.
Je suis partisan de la logique suivante : 1 application = 1 base de données
Et même carrément : 1 application = 1 cluster
Dans votre cas il serait préférable de partir sur 1 base de données qui contient 1 schéma central (pour les infos globales) + 1 schéma par client.
Cordialement,
Cordialement,
Sébastien.
Hors ligne
Bonjour,
Oui je suis parti sur cette option là (schema central + schema / client), j'ai en effet remarqué dans mes recherches que l'inter base est assez couteux (que ce soit dblink ou postgres_fdw).
Pour mon information, quelle la taille de votre base de données (sans être forcément précis, plutôt une mesure comme "quelques dizaines de Mo / Go"...) ?
Merci par avance,
Hors ligne
Bonjour,
C'était pour un portail web donc pas très volumineux (moins d'1 Go de données à tout casser).
Cordialement,
Sébastien.
Hors ligne
Bonjour,
Merci à vous deux.
Hors ligne
Bonjour,
Il ne me semble pas avoir trouvé de discussion sur ce sujet.
J'ai une problématique simple sur une application :
- Une DB "mère" dans laquelle se retrouve des infos "globales"
- Une DB par client. Chaque DB client est identique.Ma question est donc simple. D'un point de vue performance vaut-il mieux une DB avec un schema public par client, ou une seule DB avec un schema par client ?
D'un point de vue montée en charge des données sur un schema, quel serait l'impact sur les autres schema puisqu'ils seraient dans la même DB ?Après plusieurs recherches sur internet, ça reste assez vague... Une idée globale semble sortir tout de même, la méthode multiple DB est "ancienne", alors que la multiple schema est "moderne".
Mais rarement de discussion sur les performances.
Merci par avance,
Vous n'avez pas bien cherché : Une seule base de données ou plusieurs ?
De plus PostGreSQL n'est pas multibase dans le sens ou il n'est pas possible de faire des requêtes (SELECT, INSERT, UPDATE, DELETE) facilement entre différentes bases (il faut passer par des db_link) et encore moins des transactions entre différentes bases...
Enfin la catastrophe arrive si vous considérez le point de vue des sauvegardes/restauration. En effet rien ne permet der synchroniser la sauvegardes des différentes bases, ce qui fait qu'à la restauration vous pouvez avoir des factures sans client, des lignes de commande sans commande.....
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Enfin la catastrophe arrive si vous considérez le point de vue des sauvegardes/restauration.
C'est clair que si vous ne respectez pas les conditions d'utilisation, toutes les catastrophes peuvent arriver 
Guillaume.
Hors ligne
don't feed the troll
Hors ligne
Pages : 1
