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).
Partager