On désire alimenter plusieurs tables via une vue.
--> la vue
CREATE VIEW V_Clients_Commandes (id_client,nom_client,tel_client,mobile_client,date_commande,etat_commande,date_livraison) AS
SELECT cli.IDClient,cli.NomClient,cli.Tel,cli.Mobilephone,com.DateCommande,com.EtatCommande,com.DateLivraison
FROM Clients cli inner join Commandes com
ON cli.IDClient = com.IDClient
--> Les tables
CREATE TABLE dbo.Clients(
IDClient int IDENTITY(1,1) NOT NULL PRIMARY KEY,
NomClient varchar(20) NULL,
Tel varchar(20) NULL,
Mobilephone [varchar](20) NULL
)
CREATE TABLE dbo.Commandes(
IDCommande int IDENTITY(1,1) NOT NULL PRIMARY KEY,
IDClient int NOT NULL,
EtatCommande varchar(20) NULL,
DateCommande datetime NULL,
DateLivraison datetime NULL,
CONSTRAINT FK_IDCLI FOREIGN KEY (IDClient) REFERENCES Clients(IDClient)
)
--> Essaie d'insertion
INSERT INTO V_Clients_Commandes (nom_client,tel_client,mobile_client,date_commande,etat_commande,date_livraison)
VALUES ('ZINZINDOHOUE','0102XXXXXX','06XXXXXXXX',GETDATE(),'Non livrée',null)
--> échec de l'INSERT.
/*
Msg 4405, Niveau 16, État 1, Ligne 1
La vue ou la fonction 'V_Clients_Commandes' ne peut pas être mise à jour car la modification porte sur plusieurs tables de base.
*/
Vous devez être identifié pour poster un commentaire.
On désire mettre à jour plusieurs tables via une vue.
--> La vue
CREATE VIEW V_Clients_Commandes (id_client,nom_client,tel_client,mobile_client,date_commande,etat_commande,date_livraison) AS
SELECT cli.IDClient,cli.NomClient,cli.Tel,cli.Mobilephone,com.DateCommande,com.EtatCommande,com.DateLivraison
FROM Clients cli inner join Commandes com
ON cli.IDClient = com.IDClient
--> Les tables membres de la vue
CREATE TABLE dbo.Clients(
IDClient int IDENTITY(1,1) NOT NULL PRIMARY KEY,
NomClient varchar(20) NULL,
Tel varchar(20) NULL,
Mobilephone [varchar](20) NULL
)
CREATE TABLE dbo.Commandes(
IDCommande int IDENTITY(1,1) NOT NULL PRIMARY KEY,
IDClient int NOT NULL,
EtatCommande varchar(20) NULL,
DateCommande datetime NULL,
DateLivraison datetime NULL,
CONSTRAINT FK_IDCLI FOREIGN KEY (IDClient) REFERENCES Clients(IDClient)
)
--> essaie de MAJ de la vue
UPDATE V_Clients_Commandes
SET tel_client = '0320XXXXXX',
etat_commande ='Livrée',
date_livraison = GETDATE()
WHERE nom_client = 'ZINZINDOHOUE'
--> échec du UPDATE.
/*
Msg 4405, Niveau 16, État 1, Ligne 1
La vue ou la fonction 'V_Clients_Commandes' ne peut pas être mise à jour car la modification porte sur plusieurs tables de base.
*/
Vous devez être identifié pour poster un commentaire.
La norme SQL prévoit quelques fonctions pour le traitement des littéraux*. La fonction TRANSLATE fait partie des standards de la norme SQL. Cette fonction est implémentée nativement dans Oracle, dans DB2, dans PostgreSQL,... mais pas dans SQL SERVER 2012 ! MS n'arrête pas de faire évoluer son SGBD SQL SERVER en implémentant de nouvelles fonctionnalités afin de faciliter la tâche aux DBAs/Développeurs. Mais ce que je ne comprends pas c'est le fait que certaines fonctions SQL très pratiques ne sont toujours pas encore implémentées dans SQL SERVER 2012 ! Dans ce billet nous allons écrire pour SQL SERVER la fonction TRANSLATE en T-SQL et en CLR (C# .NET) puis montrer quelques applications pratiques de cette fonction.
Vous devez être identifié pour poster un commentaire.
Suite à une question posée sur le forum ici voici une tentative d'explication du problème constaté et des pistes de contournement.
Vous devez être identifié pour poster un commentaire.
Est-ce qu'il existe sous SQL SERVER une fonction native qui retourne le nombre de caractères d'une chaîne ? la réponse à cette question est NON. Jusqu'à ce jour (jour où j'écris ce petit billet), SQL Server ne dispose pas de fonction native qui retourne le nombre de caractères d'une chaîne. La fonction LEN disponible sous SQL Server retourne le nombre de caractères de l'expression de type chaîne spécifiée, à l'exception des espaces de droite. Pourquoi cette exception ? Pourquoi SQL Server ne met pas à disposition une fonction équivalente à LENGTH (sous ORACLE) ?
Vous devez être identifié pour poster un commentaire.
, zinzineti Pourquoi la fonction TRIM n'est pas disponible de façon native sous SQL SERVER ? Chaque fois que je veux supprimer les espaces à gauche et à droite d'une chaîne, je fais la même acrobatie du genre LTRIM(RTIM (machaine)). Et si en plus il y a des REPLACE et des SUBSTRING à faire le code devient moins lisible ... Et je demande ce que ça coûte à MS de mettre à disposition la fonction TRIM sous T-SQL ?
Vous devez être identifié pour poster un commentaire.
, zinzineti En T-SQL la fonction SUBSTRING (c,p,n) retourne n caractères de c (à partir de la gauche) à partir de la position p. Et si je veux retourner n caractères de c à partir de la droite depuis la position ? Et si je veux retourner une sous-chaîne de c bornées entre les positions p1 et p2 ? c'est à dire une fonction du genre BETWEEN_STR (c, p1, p2) qui retournerait une sous chaine de c compris entre les positions p1 et p2 ?
Vous devez être identifié pour poster un commentaire.
La fonction Split de découpage d'une chaîne de caractère en fonction d'un séparateur n'existe pas encore nativement sous T-SQL. Le besoin et la place de cette fonction dans un SGBD n'est plus à démontrer. En espérant que cette fonction soit présente dans la version suivante de SQL SERVER 2012, voici une fonction CLR codée en C# .NET
Vous devez être identifié pour poster un commentaire.
Le SGBD ORACLE offre le package UTL_HTTP qui permet d’interroger directement une url. La principale application de ce mécanisme est la consommation de service web. De tel mécanisme permet par exemple de suivre et de gérer en temps réel dans une base de données la variation du taux de change Euros Dollars. Notons au passage que la conversion Euros Dollars fluctue de façon significative au cours d'une même journée. SQL Server (avec SSIS) offre des composants drag-and-drop pour consommer des services web, mais pas de fonction directement utilisable dans du T-SQL ! Il n'est donc pas possible dans une procédure T-SQL (sous SQL SERVER 2008R2) d'obtenir directement la conversion Euros-Dollars en interrogeant un web service public http://www.webservicex.net/currencyconvertor.asmx?op=ConversionRate ! Une idée ?
Vous devez être identifié pour poster un commentaire.
Depuis sa version 8.1.6 ORACLE met à disposition les fonctions UTL_INADDR.GET_HOST_ADDRESS et UTL_INADDR.GET_HOST_NAME qui permettent respectivement de recupérer l'adresse ip et le nom d'une machine distante ou locale. Son équivalement SQL SERVER n'existe pas [jusqu'à SQL SERVER 2008 R2]. J'ai vu ça et là des tentatives de conception d'une telle fonction sous SQL SERVER. Preuve du besoin d'une telle fonction pour des traitements T-SQL. Les tentatives de création de telles fonctions font recours à des commandes systèmes ping, ipconfig ou nbtstat avec traitement de chaines de caractères. Mais l'un des principaux problèmes est que les chaines de caractères retournées par ces commandes dépendent de la langue de l'OS sans parler des problèmes de performances. Voici une fonction CLR pour SQL SERVER.
Vous devez être identifié pour poster un commentaire.
, zinzineti Quels sont les utilisateurs qui sont actuellement connectés à une instance de base de données ? Depuis quand sont-ils connectés ? leurs sessions sont-elles actives ? Quelles sont les applications qui sont connectées aux bases de données ? Quels comptes utilisent ces applications ?
Vous devez être identifié pour poster un commentaire.
Les métadonnées permettent de décrire le rôle et la signification des objets d'une base de données. Les métadonnées représentent en quelque sorte le dictionnaire des objets de la base. Voici une procédure stockée qui permet à la fois de visualiser, d'ajouter, de mettre à jour et de supprimer des métadonnées au niveau database. Les métadonnées peuvent être posées au niveau : base - schema - table - colonne - index - filegroup - datafile - ....
Voici une procédure stockée qui permet à la fois de visualiser, d'ajouter, de mettre à jour et de supprimer des métadonnées au niveau base.
Vous devez être identifié pour poster un commentaire.
Etienne ZINZINDOHOUE SQL SERVER
Etienne ZINZINDOHOUE
| Lun | Mar | Mer | Jeu | Ven | Sam | Dim |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 |
Il est possible d'utiliser l'Active Directory (AD) comme source de données, pour mettre à jour des tables d'une base de données SQL SERVER. Les tables en question peuvent contenir des informations relatives aux :
¤ employés
¤ ordinateurs d'une entreprise (ou d'une organisation)
¤ ...
Dans ce billet nous allons voir comment utiliser l'AD comme source pour mettre à jour une table de la base de données.
]suite
Avant toute opération d'optimisation d'une base de données, il est indispensable de vérifier rapidement les options automatiques de configuration de la base. Les incontournables :
--> AUTO_SHRINK = OFF
--> AUTO_CREATE_STATISTICS = ON
--> AUTO_UPDATE_STATISTICS = ON
--> AUTO_UPDATE_STATISTICS_ASYNC = OFF
]suite
Quelques requêtes pour auditer le cache de procédures
]suite
S'il est vrai que les index (les bons) participent à l'amélioration des performances d'une base de données,il ne faut pas perdre de vue que sa maintenance à un coût et donc pénalisant pour la performance. Alors comment trouver, au profit de la performance, le juste milieu ?. Voici une série de requêtes qui permettent de :
--> Afficher le nombre d'index manquants par base sur une instance
--> Afficher les index manquants et leur bénéfice
--> Afficher le coût des index non utilisés pour décider de leur suppression ou pas.
--> Mettre en perspective les index utilisés et leur coût de maintenance
]suite
Si en toute connaissance de cause vous décidez de basculer toutes les bases de données utilisateurs d'une instance SQL Server (2005 ou 2008) en mode de récupération FULL alors ce script peut vous éviter de perdre du temps à faire une tâche répétitive...
]suite
Pour écconomiser de l'espace de stockage des données des tables, on est souvent confronté au choix du type CHAR ou VARCHAR.
Pour une colonne dont la longueur est fixe, il n'y a pas de doute sur le choix du type de colonne : c'est CHAR qu'il faut utiliser. Mais lorsque la longueur de la colonne est variable, il faut se poser la question du choix du type de colonne. Ce n'est pas parce que les données dans la colonne varie qu'il faut systématiquement choisir le type VARCHAR.
Si la longueur de la colonne varie et est majoritairement supérieure à 4 caractères, il faut choisir le type VARCHAR.
Autrement dit même si la colonne est variable et si la longueur des données est majoritairement inférieure ou égale à 4 caractères il faut choisir le type CHAR. ]suite
Dans les "Call Centers", une phase importante de la préparation d'une campagne d'appels sortant (Outbound calls) consiste à passer la table d'appels et plus précisément la colonne "Numéro de téléphone" dans une moulinette afin d'avoir des numéros de téléphones valides. Si la table d'appels contient un nombre important de faux numéros c'est sûr que la campagne ne sera pas fructueuse.
Voici une fonction SQL qui permet de nettoyer et de valider les numéros de téléphones.
L'un des objectifs principaux de tous les SGBD est de réduire les entrées/sorties (E/S) disque car les lectures et écritures sur le disque font partie des opérations les plus consommatrices de ressources. SQL Server pour atteindre cet objectif crée un pool de mémoires tampons pour garder les pages de la base de données lues en mémoire.
De façon standard les systèmes d'exploitation Microsoft Windows 32 bits peuvent adresser une mémoire maximale de 4 Go.
Dans ce cas, 2Go sont reservés pour l'OS et 2Go pour les applications. La mémoire étant un élément fondamental pour le bon fonctionnement du SGBD, comment permettre au moteur SQL de disposer d'une quantité de mémoire supérieure à 2Go sur un OS 32 bits ? Deux commutateurs permettent de résoudre ce problème afin d'allouer plus de 2Go de mémoire à SQL SERVER, il s'agit de /3GB et /PAE.
]suite
Le nombre et le type de processeur influencent la performance d'un serveur. Une fois le serveur SQL mis en place, il est généralement difficile de décider après de changer de type de CPU ou d'en augmenter le nombre; comme on peut le faire avec les autres composants matériel de la machine : mémoire ou disque dur. En cas de dégradation des performances liées à l'utilisation de CPU que faut-il faire ?
Quatre approches de solution :
¤ Checkup des options avancées relatives à la configuration du CPU.
¤ Identifier et optimiser les requêtes les plus consommatrices de CPU : Reécriture des requêtes, création des bons index,..(En général, pour une base de données en production il n'est plus possible de modifier le model de données)
¤ Tester l'effet (ON/OFF) de l'Hyperthreading. L'option ON/OFF de l'Hyperthreading se modifie dans le BIOS.
¤ Envisager la mise en place du "gouverneur de ressources" (introduit depuis SQL SERVER 2008) pour répartir des ressources mémoires et CPU selon la charge de travail.
]suite
SQL SERVER 2008 dispose de six types pour stocker les données date/heure :
¤ DATETIME
¤ SMALLDATETIME
¤ DATE
¤ TIME
¤ DATETIME2
¤ DATETIMEOFFSET
Les types DATETIME,SMALLDATETIME sont disponibles depuis les premières versions de SQL SERVER.
Par contre les types DATE,TIME,DATETIME2,DATETIMEOFFSET sont disponibles qu'à partir de SQL SERVER 2008.
¤ Pour le type DATETIME (stocké sur 8 octets) la date (date de référence 1er janvier 1900) est stockée sur 4 octets
et l'heure (en clock-ticks) est stockée sur 4 octets.
¤ Pour le type SMALLDATETIME (stocké sur 4 octets) la date (date de référence 1er janvier 1900) est stockée sur 2 octets
et l'heure (en minute pas en clock-ticks comme dans datetime) est stockée sur 2 octets.
¤ Pour le type DATETIME2 les choses ne sont pas simples, car :
• la date de référence est le 1 janvier 0001
• l'heure (en secondes) est stockée sur un nombre d'octets variable selon la précision
Examinons en détails comment SQL SERVER gère les types DATETIME
]suite
Lorsqu'on met en place un automate d'import/export de fichier (fichier de campagne d'appels sortants par exemple), on a besoin de :
--> tester l'existence du fichier d'import/export
--> faire l'opération d'import/export (pour ça j'utilise l'utilitaire BCP)
--> déplacer/copier/supprimer/renommer le fichier dans le repertoire d'archivage
Voici des procédures stockées qui permettent de déplacer/copier/supprimer ces fichiers de données à l'aide du T-SQL.
Identifier les login/password non sécurisés
]suite
L'idée est d'examiner l'utilisation des index non-cluster par l'optimiseur de requête.
Afin de mettre en évidence le choix du moteur de base données vis à vis des index non-cluster couvrants avec colonnes incluses ou non
]suite
Le "Tipping point" qu'on peut traduire littérallement par point de basculement, correspond à la situation où un index non cluster n'est pas utilisé par l'optimiseur dans le cas d'une requête SARGable. Je préfère utiliser le terme Zone (ou ligne) de basculement que le terme "point de basculement" (Tipping point) parce qu'il me semble que la notion de point n'existe pas dans une base de données !
En mathématique, le point de basculement existe. Par exemple lorsqu'on étudie une fonction de second dégré qui est sous la forme de f(x) = ax² + bx + c, on se rend compte que cette fonction possède un point particulier appelé EXTREMUM. Ce dernier apparaît lorsque la dérivée première de la fonction s'annule et change de signe. Là il s'agit bien d'un POINT de basculement!
Le même phénomène peut être mis en évidence en Physique, lorsqu'on s'interesse à l'étude des trajectoires paraboliques. L'exemple le plus simple dans ce cas est l'étude de la trajectoire d'une balle de basket lorsqu'un joueur fait un tir à 3 points. La trajectoire décrite par la balle est telle que lors du lancement, elle monte, atteint une hauteur maximale puis redescend dans le panier (si le tir est bon !). L'instant où la balle atteint une hauteur maximale (encore appelé flêche) est un POINT de basculement.
Mais en base de données il n'existe pas de POINT ! il existe des lignes (suite de colonnes).
Pour revenir à la zone de basculement dans la cas d'une base de données, Kimberly L. Tripp a publié un article sur le sujet.
Elle a présenté une méthode théorique d'ESTIMATION de cette zone rouge. Disons-le tout de suite, ce n'est qu'une estimation car beaucoup de paramètres peuvent influencer cette zone. La seule façon de savoir si l'optimiseur n'utilsera pas un index non cluster c'est de faire le test et analyser le plan d'exécution.
Voici néanmoins une requête qui permet d'obtenir pour chaque table d'une base de données les limites théoriques de la zone de basculement
]suite
Quels sont les conditions pour créer un index sur une colonne calculée ou une vue ?
Voici un scénario pour mettre en évidence les pré-réquis.
]suite
Peut-on créer un index sur une colonne non déterministe ?
Qu'est ce qu'une colonne déterministe ou non ? comment les identifier ?
]suite
Généralement le temps CPU et le nombre de pages logiques lues sont les indicateurs de performance d'une requête.
Pour obtenir les valeurs de ces indicateurs SQL Server met à disposition les commandes :
SET STATISTICS IO ON
SET STATISTICS TIME ON
Ces commandes fournissent beaucoup d'informations et donc engendrent des fois une perte de temps. Par exemple si on travaille sous SSMS (SQL Server Management Studio), les résultats de la requête sont présentés dans l'onglet "Résultats" et les indicateurs de performances dans l'onglet "Messages". Et il y en a un paquet alors que la plupart du temps c'est le nombre de pages logiques lues qui est l'indicateur le plus fiable car le temps CPU varie de façon aléatoire pour une même requête et pour une même base dont l'état n'a pas changé !
]suite
Quelles sont les requêtes les plus consommatrices de CPU sur une instance SQL Server?
Quelles sont les dernières requêtes exécutées sur une instance SQL Server ?
Quelles sont les requêtes les + fréquemment exécutées sur une instance SQL Server ?
]suite
L'intégrité référentielle ou contrainte de clé étrangère (CONSTRAINT FOREIGN KEY) permet de contrôler la validité, la cohérence et la consistance des données dans une base. Ce mécanisme assure donc une meilleure qualité des données. Elle met également en exergue les liens entre les tables et permet ainsi d'avoir une bonne visibilité de la structure de la base de données. À travers des exemples simples [mais pas choisit au hazard ;-)], nous allons examiner l'impact de l'intégrité référentielle sur la performance des requêtes. Cette analyse va nous conduire à mettre en évidence les situations où on peut être amené à désactiver/activer la contrainte de clé étrangère afin d'optimiser la performance des requêtes.
]suite
L'option ISO_WEEK pour la fonction DATEPART n'existe pas sous SQL SERVER 2005. Sous SQL SERVER 2008 et > Cette option retourne le numéro de semaine pour une date, telle que définie par la norme ISO 8601.
La norme ISO pour la numérotation des semaines impose que :
--> la semaine numéro 1 d'une année correspond à la semaine où tombe le premier jeudi de l'année.
--> la semaine commence le lundi
Cette norme ISO est conforme aux calendriers actuels utilisés dans la plupart des pays européens et africains (certains africains attachés aux rapports directs avec la nature continuent de prendre comme référence du début du mois, l'apparition du croissant de lune ...)
Voyons concrètement le mécanisme de numérotation ISO pour la semaine et son impact sous SQL SERVER]suite
Copyright © 2000-2012 - www.developpez.com