Après ce commentaire à l'une de mes questions, je me demande s'il vaut mieux utiliser une base de données avec des schémas X ou vice versa.
Ma situation: je développe une application web où, lorsque les gens s'inscrivent, je crée (en fait) une base de données (non, ce n'est pas un réseau social: chacun doit avoir accès à ses propres données et ne jamais voir les données de l'autre utilisateur) .
C'est comme ça que j'ai utilisé pour la version précédente de mon application (qui est toujours en cours d'exécution sur MySQL): via l'API Plesk, pour chaque inscription, je fais:
- Créer un utilisateur de base de données avec des privilèges limités;
- Créer une base de données accessible uniquement par l'utilisateur créé précédemment et le superutilisateur (pour la maintenance)
- Remplir la base de données
Maintenant, je vais devoir faire de même avec PostgreSQL (le projet est en train de mûrir et MySQL ... ne répond pas à tous les besoins).
J'ai besoin d'avoir toutes les sauvegardes de bases de données / schémas indépendantes: pg_dump fonctionne parfaitement dans les deux sens, et de même pour les utilisateurs qui peuvent être configurés pour accéder à un seul schéma ou à une base de données.
Donc, en supposant que vous soyez des utilisateurs PostgreSQL plus expérimentés que moi, quelle est selon vous la meilleure solution pour ma situation, et pourquoi?
Y aura-t-il des différences de performances en utilisant la base de données $ x au lieu des schémas $ x? Et quelle solution sera la meilleure à maintenir à l'avenir (fiabilité)?
Toutes mes bases de données / schémas auront toujours la même structure!
Pour le problème des sauvegardes (en utilisant pg_dump), il est peut-être préférable d'utiliser une base de données et de nombreux schémas, vider tous les schémas à la fois: la récupération sera assez simple en chargeant le vidage principal dans une machine de développement, puis en vidant et en restaurant juste le schéma nécessaire: là est une étape supplémentaire, mais vider tous les schémas semble plus rapide que de les vider un par un.
MISE À JOUR 2012
Eh bien, la structure et la conception de l'application ont tellement changé au cours de ces deux dernières années. J'utilise toujours l' one db with many schemas
approche, mais j'ai quand même une base de données pour chaque version de mon application:
Db myapp_01
\_ my_customer_foo_schema
\_ my_customer_bar_schema
Db myapp_02
\_ my_customer_foo_schema
\_ my_customer_bar_schema
Pour les sauvegardes, je vide régulièrement chaque base de données, puis je déplace les sauvegardes sur le serveur de développement.
J'utilise également la sauvegarde PITR / WAL mais, comme je l'ai déjà dit, il est peu probable que je doive restaurer toutes les bases de données en même temps ... donc elle sera probablement rejetée cette année (dans ma situation, ce n'est pas la meilleure approche ).
L'approche one-db-many-schema a très bien fonctionné pour moi depuis maintenant, même si la structure de l'application est totalement modifiée:
J'ai presque oublié: toutes mes bases de données / schémas auront toujours la même structure!
... maintenant, chaque schéma a sa propre structure qui change de manière dynamique en fonction du flux de données des utilisateurs.