Trouver les contraintes qui ne sont pas fiables

Publié le par
2

Pour faciliter le chargement de données, il est parfois nécessaire de désactiver une contrainte de domaine (CHECK) ou de clé étrangère, puis de la réactiver dès la fin du chargement.

Si l’on écrit :

ALTER TABLE maTable CHECK CONSTRAINT maContrainte

La contrainte est alors marquée comme non-fiable, et le moteur de bases de données ne s’en sert plus dans ses plans de requête.
Pire, cela signifie que l’intégrité des données qui ont été importées est alors mise en défaut.

Il faut donc écrire :

ALTER TABLE maTable WITH CHECK CHECK CONSTRAINT maContrainte

Pour que les valeurs ajoutées pendant que la contrainte était désactivée soient vérifiées.

Voici donc une petite requête pour trouver les contraintes qui ne sont plus fiables pour le moteur de base de données …

Lire la suite →

Convertir des coordonnées sexagésimales en degrés et en radians

Publié le par
Répondre

Souvent, les coordonnées géographiques sont exprimées en degrés, minutes, secondes.
Mais nos systèmes sont bien plus à l’aise avec des nombres décimaux, et il est donc nécessaire de convertir des coordonnées sexagésimales en degrés ou bien en radians.
Voici une petite fonction pour le faire …

Lire la suite →

Vérifier l’unicité d’une position avec le type GEOGRAPHY sous SQL Server 2008

Publié le par
Répondre

SQL Server 2008 a introduit de nombreux nouveaux types de données, dont le type de données géographiques GEOGRAPHY.
Ce n’est pas un type habituel, puisque c’est un type CLR.NET intégré à SQL Server.

L’avantage présenté par l’intégration de ce type est l’ensemble des méthodes standard « livrées » avec ce type, qui permettent d’extraire très simplement une latitude (attribut Lat), une longitude (attribut Long), ou encore de connaître la distance entre deux points géographiques avec la méthode STDistance.

Mais il devient alors plus complexe de garantir l’unicité de positions dans une table où l’on stocke la celle de plusieurs villes.
En effet, si une colonne de ce type est spécifiée comme clé d’une contrainte d’unicité, le moteur de base de données SQL Server lève une exception.

Est-il possible de contourner ce problème ?

Lire la suite →

Empêcher un utilisateur de consulter le code source d’un objet de base de données (procédure stockée, fonction, trigger, vue, …)

Publié le par
Répondre

On demande parfois comment on peut crypter le code d’un objet de base de données (procédure stockée, trigger, fonction, vue, …) afin qu’un utilisateur ou qu’un groupe d’utilisateurs ne puisse pas en consulter le code.

Or il faut bien se rappeler que le cryptage d’un objet de base de données implique que celui-ci soit décrypté lors de chacune de ses exécutions, ce qui peut infliger au serveur de base de données une consommation de ressources élevée, peu souhaitable dans un environnement OLTP ou pour un serveur OLAP fortement sollicité.

Une alternative bien simple existe pourtant : le refus d’autorisation.
Voyons comment l’utiliser …
Lire la suite →