Base dupliquée Vs View Vs ?

Bonjour à tous,

Nous avons une base de données de production avec des données sensibles.
Un prestataire extérieur à besoin d'accéder à certaines tables ( et éventuellement certains champs) et ceci en temps réel

Mais je veux pas qu'il ait un accès direct aux tables de notre base de production, car en cas de blocage d'une table (par exemple), cela pourrait faire planter des traitements importants.

Et j'aimerais avoir votre avis sur les solutions possibles et celle qui vous semble la meilleure.

J'en ai répertorié 2:

Création de VIEW pour chaque table pour lesquelles je veux autoriser l'accès, ainsi je pourrais filtrer les colonnes. Je pensais créer ces Views dans une autre base (si c'est possible) dédiée.
Répliquer en TEMPS REEL tout ou partie de la base de données de production dans une base dédiée.

La notion de temps réel est importante car le logiciel qui accédera à ces données doit permettre de prendre des décisions très rapidement suivant l'état des données à un moment précis.

La solution des VIEW me parait la plus intéressante, mais je crains pour les performances (plusieurs milliers voir millions d'enregistrements dans certaines tables qui sont mis à jour très souvent).

La réplication en temps réelle, je ne connais pas du tout et j'ai un doute sur le coté "temps réel" et aussi sur les performances.

Si vous avez d'autres idées, je suis preneur.

Merci à tous pour votre aide

Marc

Bonjour, ce que tu veux ressemble à des accès type "service". Ne faudrait-il pas envisager une MQ avec paramètre d'appel et réponse en sortie ? As-tu un service architecture dans ta boîte qui pourrait t'aiguiller ?

Bonjour,

Quelle que soit la solution retenue, la mise en oeuvre de vues est très fortement recommandée, y compris pour votre usage interne :
Les requêtes ne devraient jamais s'appuyer sur les tables et toujours sur les vues, c'est ce qui permet de garantir l'indépendance des données et des traitements : si la table évolue, grâce à l'utilisation d'une vue, les traitements ne sont pas impactés.

Par ailleurs, une vue ne dégrade pas les temps d'accès (pas plus que la même requête directement sur la table).

L'utilisation d'une MQ consiste à délivrer les données sous forme séquentielle, je ne pense pas que ça corresponde au besoin.

La solution la plus économique et la plus simple est donc à mon sens de mettre en place
- pour le prestataire, des vues qui ne déclarent que les colonnes souhaitées
- pour votre usage interne, des vues plus ou moins restrictives selon vos besoins internes

Et que ce soit en interne ou pour vos prestataires, supprimez tous les privilèges sur les tables (hors admin et exploitation bien sûr ;)) et n'accordez que des privilèges sur les vues

Pour ce qui concerne les blocages éventuels, ceux-ci sont possible que les requêtes soient sur des vues ou des tables, ça ne changera rien.
Idem pour les requêtes du prestataire ou de votre propre S.I.
Ce qui compte c'est de bien gérer l'isolation et les verrous.
Pour limiter les risques, vous pouvez publier des services encapsulant les requêtes requises pour le prestataire (requêtes qui utiliseront là encore les vues).

Citation:

---

Envoyé par Darkzinus

Bonjour, ce que tu veux ressemble à des accès type "service". Ne faudrait-il pas envisager une MQ avec paramètre d'appel et réponse en sortie ? As-tu un service architecture dans ta boîte qui pourrait t'aiguiller ?

---

Merci pour ton aide, nous avons un service infra structure qui peut m'aider et je vais leur proposer cette solution, mais elle me semble un peu compliqué.
Merci
Marc

Citation:

---

Envoyé par escartefigue

Bonjour,

Quelle que soit la solution retenue, la mise en oeuvre de vues est très fortement recommandée, y compris pour votre usage interne :
Les requêtes ne devraient jamais s'appuyer sur les tables et toujours sur les vues, c'est ce qui permet de garantir l'indépendance des données et des traitements : si la table évolue, grâce à l'utilisation d'une vue, les traitements ne sont pas impactés.

Par ailleurs, une vue ne dégrade pas les temps d'accès (pas plus que la même requête directement sur la table).

L'utilisation d'une MQ consiste à délivrer les données sous forme séquentielle, je ne pense pas que ça corresponde au besoin.

La solution la plus économique et la plus simple est donc à mon sens de mettre en place
- pour le prestataire, des vues qui ne déclarent que les colonnes souhaitées
- pour votre usage interne, des vues plus ou moins restrictives selon vos besoins internes

Et que ce soit en interne ou pour vos prestataires, supprimez tous les privilèges sur les tables (hors admin et exploitation bien sûr ;)) et n'accordez que des privilèges sur les vues

Pour ce qui concerne les blocages éventuels, ceux-ci sont possible que les requêtes soient sur des vues ou des tables, ça ne changera rien.
Idem pour les requêtes du prestataire ou de votre propre S.I.
Ce qui compte c'est de bien gérer l'isolation et les verrous.
Pour limiter les risques, vous pouvez publier des services encapsulant les requêtes requises pour le prestataire (requêtes qui utiliseront là encore les vues).

---

Bonjour et merci d'avoir pris le temps de me répondre avec précision.

Ton idée de faire de travailler avec des vues est intéressante.
Pour les performances, je suis d'accord qu'en lecture cela ne changera rien, mais en écriture, si j'ai beaucoup de view sur des tables avec des centaines de milliers d'enregistrements et qui sont fréquement mis à jour, logiquement ca devrait avoir un impact.
Mais je pense que la meilleure manière de le savoir et de faire des tests en réel.

Une chose que j'ai oublié de préciser, il s'agit de la base de données d'un progiciel, nous n'avons pas la possibilité de la modifier comme on le souhaite. On pourra créer des view pour des besoins annexes (logiciels maison), mais pas beaucoup plus.

Merci à ton aide. Je vais soumettre ces idées au DBA. Je vous tiendrai au courant lorsque l'on aura choisi une solution. Pour l'instant, on a choisi le clonage en temps réel, sans doute car le plus rapide à mettre en oeuvre

Marc