TRUNCATE et DELETE peuvent avoir le même effet sur une table si le DELETE n’a pas de clause WHERE.
Mais est-ce bien la même chose qui se passe au niveau des données ?
Archives pour la catégorie Moteur de base de données SQL Server
Trouver l’espace disque occupé par les fichiers, et l’espace libre dans ceux-ci
Voici quelques requêtes pour vous permettre d’auditer vos fichiers de base de données :
Lire la suite
Une procédure pour connaître l’état physique et l’utilisation des index
Voici une petite procédure stockée qui permet de connaître l’état physique des index (nombre de pages du niveau feuille, fragmentation et taux d’utilisation des pages) en même temps que la façon dont ils sont utilisés (nombres de seeks et de scans, …).
Elle est utilisable pour collecter ces statistiques sur l’ensemble d’une base de données, ou bien sur une table en particulier
Lire la suite
Une procédure stockée pour défragmenter les indexes sous SQL Server 2005 et ultérieur
Voici une petite procédure stockée que l’on peut exécuter régulièrement dans un job pour défragmenter les indexes de toutes les bases de données, en fixant les seuils de nombre de page et de pourcentage moyen de fragmentation
Trouver le nombre de lignes de toutes les tables d’une base de données
Il est intéressant, pour suivre l’évolution d’une base de données, et pour prévoir l’espace disque nécessaire, de connaître le nombre de lignes que contient chaque table.
Ce qui vient en premier à l’esprit lorsqu’on souhaite quantifier les lignes, c’est d’exécuter un SELECT COUNT(*) sur chacune des tables à travers un curseur sur chacune des tables de la base de données, ou encore d’user de la procédure stockée système sp_spaceused sur le même modèle.
Mais il est évident que ce n’est pas performant et le résultat est long à obtenir.
Voyons comment obtenir cela sans effort, ni pour nous, ni pour le moteur de base de données …
Trouver les contraintes qui ne sont pas fiables
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 …
Télécharger les filtres pour la recherche en texte intégral dans des documents Office 2007
Voici où vous pourrez trouver la liste des filtres pour les documents de type .docx., .xlsx, .pptx, … qui vous permettront d’utiliser la recherche en texte intégral dans ce type de documents sous SQL Server.
Bonne indexation full-text !
ElSuket
Lister les types définis par l’utilisateur, avec les défauts et règles qui leur sont liés, et les scripter
Voici une petite requête qui permet de retrouver la liste de tous les types définis par l’utilisateur …
Lire la suite
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 ?
Les jointures triangulaires
Nous avons tous entendu qu’écrire du code ensembliste pour gérer des données dans une base de données est la meilleure façon d’obtenir des performances correctes.
Il est vrai qu’il est difficile pour un développeur ayant une expérience du développement d’applications, en quelque langage de programmation que ce soit, de passer du code procédural, qui, en outre, traite des jeux de données extraits de bases de données « ligne par ligne », à un langage conçu pour manipuler des ensembles de données.
Nous n’aborderons pas ici l’utilisation, à proscrire, des curseurs et des boucles utilisant la commande WHILE, mais nous allons voir que, si l’on croit avoir écrit du code ensembliste, il s’agit en fait de code procédural, et qu’il peut s’avérer être contre-performant. Lire la suite