Discussion :

[sihem_info]

Bonjour a tous ,
Je vais bientôt commencer un projet d'archivage de données pour alléger la base de production.
Dans la configuration spécifique de la base d'archive, il a été décidé qu'elle ne contiendrait pas de clés étrangères (FK), ce qui rend la base plus fragile.
En effet, un TRUNCATE TABLE pourrait être effectué sur toutes les tables sans restriction.
Je sais qu'il est important de gérer cela du côté de la sécurité, mais j'aimerais connaître vos avis sur l'utilisation des vues indexées pour protéger ces données.
https://learn.microsoft.com/en-us/sq...l-server-ver16
Qu'en pensez-vous ?

[gabi7756]

Bonjour,
Navré je répond à une question par une autre mais je ne comprends pas :

Dans la configuration spécifique de la base d'archive, il a été décidé qu'elle ne contiendrait pas de clés étrangères (FK), ce qui rend la base plus fragile.

Pourquoi elle ne devrait plus contenir de clé étrangère ? Pour alléger la base ??
Cdt

[Michel.Priori]

mais j'aimerais connaître vos avis sur l'utilisation des vues indexées pour protéger ces données.

Et zut.

J'en ai marre de cette mentalité qui essaie de gérer la chose par les proxy.
De mon temps on avait une expression pour ça : "mettre un cautère sur une jambe de bois" et son pendant "s'adresser au bon dieu plutôt qu'à ces saints".
Dans la même veine de proposition pourquoi pas imposer la ceinture de sécurité contre la noyade ; les statistiques sont formelles.

Il est temps de proposer à la direction de mettre les archives dans un "datalake" le moins contraint possible.
Si vous ne voyez pas l'intérêt des FK ou autres contraintes autant mettre la données dans un fichier plat et laisser l'indexation textuelle faire son travail. Vive Big table.
De toutes façons, personne ne modifie les archives ... et si le programme d'ingestion est bien fait "y a pas de raison"

[SQLpro]

B...
Dans la configuration spécifique de la base d'archive, il a été décidé qu'elle ne contiendrait pas de clés étrangères (FK), ce qui rend la base plus fragile.
...

Outre le cautère sur jambe de bois, le fait de ne pas mettre l'intégrité référentielle déclarative (FOREIGN KEY) interdit certaines optimisations dites "sémantiques". En gros, l'optimiseur analyse les contraintes et modifie les plans d'exécution des requêtes pour aller plus vite... Bref, ce faisant, vous pourrissez les performances de vos requêtes et pourrissez aussi la base e données polluées (lignes orphelines...) ce qui vous donnera des requêtes avec des résultats faux... Double peine donc !
Pour un archivage, il est possible de "suspendre" ou supprimer les FK le temps de l'insertion des données d'archive, puis les remettre après...

A +