Bonjour à tous,
D'abord merci beaucoup pour vos réponses à mes nombreux posts, jespere pouvoir redonner à la communauté libre quand j'aurai plus d'experience!
J'ai posté ce message sur stackoverflow mais je n'ai eu aucune réponses…
Je m'interroge sur l'architecture idéale pour une base de données avec des enjeux de sécurité importants (certaines données pourraient concerner la santé des utilisateurs par exemple).
J'ai lu ce document sur les architectures multitenant dans django : https://books.agiliq.com/projects/django-multi-tenant/en/latest/index.html
Je m'interroge encore sur la bonne architecture à adopter, notamment pour la partie/table/base "utilisateurs" : schéma isolés dans base commune, bases isolés dans une app commune, tenants completement isolés en utilisant docker ?
Je voudrais eviter de mettre tous les utilisateurs dans la meme table ou dans la meme base pour des raisons de sécurité.
Cependant, je ne comprend pas bien si cest une bonne pratique de mettre chaque utilisateur dans une base séparée? Si je fais ca est ce que chaque base doit etre du meme type (par exemple une base postgres qui contient pleins de bases sqlite pour chaque utilisteur ou est ce qu elles doivent etre des bases postgres aussi? )
Je me demande aussi dans quelle mesure ca affecte les performances de procéder en faisant une base isolée par utilisateur?
Est ce que l'alternative de mettre un schema par utilisateur dans une meme base est assez "sécurisé"?
Et enfin, il y a l'aspect pratique pour faire des requetes sur mes utilistaeurs…si je les met dans des bases séparés est ce que je peux requeter avec postgres ou il faudra que je fasse des scripts pour coordonner les requetes et rassembler les resultats?
# Compromis
Posté par Guillaume Smet (site web personnel) . Évalué à 3.
Bonjour,
Déjà, il faut bien comprendre que tu ne peux pas avoir le beurre et l'argent du beurre i.e. isolation des données et capacité à requêter facilement sur l'ensemble. Du coup, c'est un compromis à trouver par rapport à ce qui est le plus important pour toi.
Ensuite, si tu utilises PostgreSQL, je pense qu'avoir des schémas séparés dans la même base est une bonne option dans plein de cas : tu peux gérer des permissions distinctes et bien isoler les données et tu peux quand même requêter sur plusieurs schémas (même si ce sera toujours moins pratique que tout avoir dans les mêmes tables). Requêter sur plusieurs bases est possible mais plus pénible.
Tu peux aussi restaurer un schéma spécifique, ce qui peut-être pratique s'il y a une grosse boulette sur un tenant qui n'impacte pas les autres.
[^] # Re: Compromis
Posté par maroufle34 . Évalué à -2. Dernière modification le 22 avril 2022 à 20:27.
On aurait peut être dû lui parler du fameux CAP théorème pour les bdd?
(je dis même pas SGBDR, pour dire à quel point je trouve ces modèles pas toujours les plus appropriés)
Bref voilà le lien sur le fameux CAP théorème.
(Je sais qu'on me voit pas, trop de votes contre, mais pas grave :))
CAP théorème
# scalability
Posté par kr1p . Évalué à 1.
Je connais le principe du cap theorem mais je ne suis pas sûr que ce soit l'objet de la question.
Il y a un aspect aussi pour des utilisateurs dans plusieurs schemas séparés (petite question : un schema cest bien la meme chose qu'une table non? ) : quid de la 'scalability'? pour une base qui contient des infos textes et éventuellement quelques images par utilisateurs, je peux mettre combien d'utilisateurs maximum dans une base unique avec des schemas séparés ?
dans le cas où les utilisateurs sont dans des bases séparées, l'outil pour coordonner et requeter reste postgres ou cest un autre outil ?
[^] # Re: scalability
Posté par maroufle34 . Évalué à -3.
En général les requêtes sont en SQL, pas sur tous les SGBDR mais beaucoup…(avec des fois des commandes bonus, attention si on change de SGBDR dans ces cas là)
Sinon ici tu as un petit tuto de normalisation de SGBDR, pour éviter de se retrouver avec des tables obèses…(D'ailleurs pourquoi mettre directement dans postgres des images, ça en général on évite, c'est trop gros une image, on mettra plutôt le lien vers cette image)
Performances BDD
[^] # Re: scalability
Posté par Guillaume Smet (site web personnel) . Évalué à 2.
Non, un schéma, c'est différent d'une table.
Dans PostgreSQL, tu as base > schéma > table. Par défaut tu as un schéma public dans une base mais tu peux avoir autant de schémas que tu veux.
Ca permet d'isoler complètement un ensemble de tables (et du coup tu peux avoir le même modèle n fois dans n schémas différents). Tu peux aussi définir le schéma par défaut quand tu te connectes et définir des droits spécifiques.
Bref, je te conseille d'en lire un peu plus sur la notion de schéma dans PostgreSQL.
[^] # Re: scalability
Posté par kr1p . Évalué à 1.
jai téléchargé pas mal de bouquins sur postgresql et je vois mieux ce qu'est un schéma (et une partition d'ailleurs!). C'était un peu confus car dans mon cours sur postgresql, le prof faisait reference aux schemas comme les définitions des tables (definition de chaque champs, des contraintes, etc.) d'une base.
Par contre je n'ai pas trouvé comment requeter sur plusieurs schémas de façon automatique si on en a des milliers (en manuel : select * from Schema1.table1, Schema2.table1 …) : faut il les taper à la main?!
[^] # Re: scalability
Posté par kr1p . Évalué à 1.
SELECT * FROM information_schema.schemata pour ceux qui chercheraient pour obtenir l'ensemble des schemas de la table…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.