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 …
Archives mensuelles : décembre 2009
Vérifier l’unicité d’une position avec le type GEOGRAPHY sous SQL Server 2008
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 ?
Obtenir une représentation sexagésimale d’une coordonnée géographique en degrés
Faisant suite à ce billet, voici une petite fonction pour représenter sexagésimalement une coordonnée géographique exprimée en degrés :
Lire la suite
Vérifier qu’un point est contenu dans un polygone de type GEOGRAPHY
Voici comment vérifier qu’un point de type GEOGRAPHY, c’est à dire une position définie par sa latitude et sa longitude, appartient à la surface définie par un polygone, toujours sous le type GEOGRAPHY
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, …)
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