Discussion :

[moimp]

Bonjour,

J'ai réalisé une application Internet accessible par abonnement (gratuit) avec un interface PHP et une base de données commune comprenant une table subscribers, une table users (il peut y avoir plusieurs utilisateurs pour un abonné) et toutes les tables de l'application.
Pour des raisons de sécurité et de confidentialité, je voudrais remplacer ma base de données unique par une base de données par abonné.
Les données d'abonnement seraient à part soit dans un fichier XML soit dans une base de données avec une seule table.

L'intérêt serait d'une part de mieux protéger les données confidentielles et d'autre part de permettre une sauvegarde séparée des données de chaque utilisateur.

J'ai cherché sur Internet mais je ne sais pas comment libeller ma question pour trouver des cours ou des informations pour l'architecture de mon application.

[Marco46]

"database schema per user"

Ya plein de choses.

[moimp]

Oui, effectivement, il y a plein de choses qui ne m'encourage pas à aller dans ce sens.
Du coup, je ne sais quoi choisir:

• Une base de données par abonné (client)
• Une base de données commune avec des tables organisées par client
• Une base de données avec des tables communes et un id client sur chaque ligne (comme je le fais actuellement) mais alors bonjour les sauvegardes individualisées!

Quels conseils pourriez vous me donner?

[Marco46]

La 3ème solution me parait de très loin la plus souhaitable.

Je ne vois pas en quoi le fait d'utiliser un schéma différent serait plus sécurisé. Si on arrive à accéder à la base de données, que les données soit dans le même schéma ou non revient à peu près au même. Ou alors vous comptiez également créer un utilisateur de la BDD pour chacun de vos users ? Ça serait horrible à gérer. Après tester qu'un user donné n'arrive pas à accéder aux données d'un autre user via les traitements disponibles doit faire partie de la liste des tests automatisés que vous devez jouer à chaque révision de la code base.

Sauvegarder les données de chaque utilisateur n'est pas non plus si terrible que ça. Ça reste une bonne grosse requête.

[moimp]

Merci pour cet avis qui a le mérite d'être clair et tranché. Avant de marquer résolu, j'attends quand même un peu de voir si d'autres auraient des avis différents.

[SQLpro]

Lisez l'article que j'ai écrit à ce sujet :
https://blog.developpez.com/sqlpro/p...ou_plusieurs_1

Ensuite tout dépend du SGBDR que vous allez utiliser. Par exemple MySQmerde ne connais pas la notion de schéma.
PostGreSQL ne permet pas des requêtes interbase sauf à passer par le dblink qui est un gouffre pour les performances...

Dans votre cas je préconise la solution multibase, car il est facile de sauvegarder base par base. La plupart des grands éditeurs comme CEGID (comptabilité) utilise ce principe avec MS SQL Server.

A +

[SQLpro]

Ou alors vous comptiez également créer un utilisateur de la BDD pour chacun de vos users ? Ça serait horrible à gérer.

Sauf que la RGPD impose cela pour pouvoir tracer les accès de manière nominative !

Le nombre d'utilisateur SQL n'a aucune influence sur la complexité ni sur les performances d'accès, mais permet d'être conforme aux attentes en matière de traçabilité des accès aux données personnelles !
Qui à accéder, à quoi, comment... Tout cela ne peut être tracé que via des audits effectués directement par le SGBDR !

A +

[Marco46]

Sauf que la RGPD impose cela pour pouvoir tracer les accès de manière nominative !

Sympa lol

J'imagine bien les GAFAM avec leurs milliards du users. On comprend pourquoi ils se battent les steacks du RGPD.

Le nombre d'utilisateur SQL n'a aucune influence sur la complexité ni sur les performances d'accès

Non certes mais à gérer merci kiki.

[SQLpro]

...Non certes mais à gérer merci kiki.

Il faut bien les gérer quelque part... Et les gérer dans la base de données c'est plus facile et portable que partout ailleurs....

Un seul exemple... Sauvegarde/restaure et mes utilisateurs sont tous opérationnels !

A +