Déterminer la validité d'une BDD

Bonjour,

Je travail sur une application qui est déployée sur plusieurs sites de production et en différentes versions. Il arrive parfois que des erreurs de déploiement ou mise à jour provoquent des incidents de production quand la BDD ne correspond pas à la version de l'application qui l'utilise.

J'ai déjà un brouillon de code qui calcul un hashcode à partir des tables, colonnes des tables, contraintes, code des fonctions et code des procstoc, sans tenir compte des données dans les tables (seule la structure compte): ca permet d'identifier à coup sure au démarrage si la BDD est de la bonne version. Mais cette je trouve cette solution est assez lourde.
La solution ultra simple d'ajouter un numéro de version de la BDD dans une des tables a été envisagée, mais elle peut être facilement modifiée par un administrateur pour contourner cette sécurité et forcer le démarrage de l'appli.

Y-a-t'il un moyen plus simple de déterminer si la BDD à laquelle l'appli se connecte est de la bonne version? A savoir structure des tables, colonnes et contrainte qui les lient + code des fonctions et des procstoc de la bonne version.
Je n'ai rien trouvé sur les forum à ce sujet.

Merci.

Le plus professionnel est de déployer les schémas de BD par intégration continue, avec un gestionnaire de code source type git.

@MaximeCh: Je suis d'accord, mais là ça ne se fait pas pour différentes raison que je ne peux pas développer ici. Il arrive qu'un dump soit installé avec une version de l'appli plus récente sur une nouvelle VM lorque que les anciennes VM de prod sont décommissionnées. Mon but est d'avoir un diagnostique de la compatibilité de la BDD dès le démarrage sans attendre qu'il y ait des incidents de prod.

Je ne vois rien à part le hash en base avec procédure stockée...

Citation:

---

Envoyé par bertry

mais elle peut être facilement modifiée par un administrateur pour contourner cette sécurité et forcer le démarrage de l'appli.

---

Alors il faudrait retirer les privilèges (voire virer ! ) l'admin qui (ab)use de ses privilèges pour... faire n'importe quoi.

Citation:

---

Envoyé par aieeeuuuuu

Alors il faudrait retirer les privilèges (voire virer ! ) l'admin qui (ab)use de ses privilèges pour... faire n'importe quoi.

---

C'est la différence que je constate entre la théorie qu'on nous enseigne en formation ou à l'école et la pratique sur le terrain. Parfois par manque de moyens et/ou la pression hierarchique on fini par bricoler pour que ça tourne quand même. Les admins ne sont (peut-être ^^) pas à virer, il font de leur mieux avec les moyens et le temps qu'on leur donne...

Ici, il s'agit de trouver une solution pour éviter des bugs en prod.

On est dans la politique ou dans la technique ?
tu te bats contre quelqu'un? contre qui? ils ont quels droits que tu n'as pas? tu as quel droit qu'ils n'ont pas? vous partagez quels droits?

Parce que niveau technique il y a un panel de mesures possibles, les hash ça me paraît de loin le plus simple, sinon un log de toutes les modifs sur le schéma, une caméra sur le poste de l'admin... :D

Je ne blame personne, mais ce qui est sûr c'est que le problème ne pourra pas être règle d'une façon technique.
Par exemple, votre calcul de HASH sur les objets en base empêchera l'appli de démarrer du jour au lendemain, même si elle est dans la bonne version, le jour où un de ces admin créera un objet supplémentaire (une fonction de test, une table pour sauvegarde telle ou telle données,...)

Par ailleurs, vous en dites peu sur le contexte, on peut donc difficilement proposer des alternatives.
Qui sont ces admins qui modifient à la main le contenu des tables ? quel est leur rôle et quels sont leurs privilèges ? (il y a sans doute moyen de réduire leur privilèges sans les empêcher de faire leur travail)

Aussi, effectuez vous souvent des restaurations en production ? pour quelles raisons ?

Ce calcul de hash est une idiotie car suivant l'accès aux données que va prendre l'optimiseur, il se peut que l'on obtiennent pas les mêmes résultats...

A +

@Tous:
Je suis d'accord avec vous tous, une petite solution technique ne suffira jamais à compenser de mauvaises pratiques qui ont fini pas s'installer. Pour ce qui est du contexte, comme il s'agit du domaine professionnel, je ne suis pas autorisé à donner de détails.

Citation:

---

Envoyé par SQLpro

Ce calcul de hash est une idiotie car suivant l'accès aux données que va prendre l'optimiseur, il se peut que l'on obtiennent pas les mêmes résultats...
A +

---

@SQLpro: Merci pour cette précision.


Pensant, sans trouver, qu'il y avait déjà des solutions clé en main dans SQL server à mon problème, j'avais créé ce post. Je vais donc le cloturer en vous remerciant de vos réponses.

Citation:

---

Envoyé par SQLpro

Ce calcul de hash est une idiotie car suivant l'accès aux données que va prendre l'optimiseur, il se peut que l'on obtiennent pas les mêmes résultats...

A +

---

ça dépend de la façon de calculer le hash

Par exemple, ceci renverra toujours la même valeur :

Code:

---

1 2 3 4 5 6 7 8 9 10

SELECT CHECKSUM_AGG(CHECKSUM(name)) FROM ( SELECT name FROM sys.objects UNION ALL SELECT name FROM sys.columns ) AS T

---